Subject: RE: [Sip] [SIP, Transport] Does sent on TCP (when msg too big) also occurs on server side?

From: "James Undery" <[email-masked]>
Date: Thu, 4 Jul 2002 17:08:25 +0100

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]

> The transaction should use the same transport (that's my 
> understanding, at least), which means the response uses the 
> same transport as the response.
> 
> It is true that the response may be bigger than the request 
> (eg if the 200 response to a INVITE without SDP), but bis-09 
> DOES take that into consideration, saying that the maximum 
> size for a request is smaller than the
> actual maximum size for a SIP UDP message, so that there is 
> "room" for the response to use UDP too, even if the response 
> is bigger than the request.
> 
> IF, however, the response becomes too big for UDP, I guess 
> that COULD be indicated to the UAC in an error response to 
> the request, but I currently don't remember which error code 
> (if such even exists...) should be used to
> indicate that. It was discussed once, but you may want to 
> check the archieve for details...

The trouble with your suggestion of an error (and it's documented in bug#184) is that you can't always return and error. Admittedly it's far fetched but a 200 response to an INVITE crosses the 64k boundary, how can you send an error without messing up the UAS.

James

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 04 Jul 2002 20:02:40 +0300

Hi James,

> The trouble with your suggestion of an error (and it's documented in bug#184) is that you can't always return and error. Admittedly it's far fetched but a 200 response to an INVITE crosses the 64k…

It's not a suggestion - it's the closest to a suggestion I can think of :) As you said yourself, it's an existing and unfixed bug, so I guess there really is no good solution at the moment.

The problem, of course, is that if the UAS sends a 4xx response it will most likely also release the call it just established (I assume that's what you meant by saying that "it will mess up the UAS"). That, of course, is stupid since the called party just has
picked up the hook (the reason why the 200 is sent), and is most likely going to receive a NEW INVITE (now using TCP) very soon anyway.

The best thing would be if the UAS can figure out how big the 200 is going to be before it even alerts the called party, or at least before the called party picks up the phone. In a "manyfolks" scenario I guess that will work, but probably not as well in cases
where the called party is alerted as soon as the INVITE is received...

Anyway, as you say, it's "far fetched", and I guess the assumption is that a 200 will never be too big. But, never forget Murphy's law... :)

Regards,

Christer Holmberg
Ericsson Finland