[Sip] Re: Defining new requests

[Gonzalo Camarillo <[e-mail]>]

Christer,

would the ITU-T be happier if we log an errata against the INFO RFC 
saying that UASs can send INFO within early dialogs?

Gonzalo

Christer Holmberg (JO/LMF) wrote:

> Hi Gonzalo,
> 
> Thanks for your reply!
> 
> 
>>it seems that some people in the ITU-T are having some issues 
>>figuring out whether or not certain requests can be sent by the UAS
> 
> within an 
> 
>>early dialog. The confusion comes from statements like this 
>>one (taken from the INFO spec):
>>
>>"     Unless stated otherwise, the protocol rules for the INFO request
>>       governing the usage of tags, Route and Record-Route,
>>       retransmission and reliability, CSeq incrementing and message
>>       formatting follow those in [1] as defined for the BYE request."
>>
>>Since a UAS does not send BYEs within an early dialog, but a non-2xx 
>>final response instead, to terminate the dialog, people assume that
> 
> INFO 
> 
>>cannot be sent in this situation either.
>>
>>Let's try to keep this in mind and clarify this point when/if 
>>we define new SIP methods.
>>
>>In any event, the clarification to this issue can be found in 
>>RFC 3398:
>>
>>"From the callee to the caller, if a message is received by a gateway
>>before the call has been answered (i.e., ANM is received) 
>>it SHOULD be encapsulated in an INFO, provided that this will not 
>>be the first SIP message sent in the backwards direction (in which 
>>case it SHOULD be encapsulated in a provisional 1xx response)."
> 
> 
> The problem is that the ITU-T interworking spec doesn't reference
> RFC3398. The spec reference the INFO RFC, and that is also where I think
> the usage rules should be defined (not in another spec, RFC3398 in this
> case, simply using the method).
> 
> The INFO RFC, as you said, currently says that INFO "follows the rules
> of BYE" (whatever that means is another question :), and the rules for
> BYE specifically says that it must not be sent backward before the
> INVITE has finished. If the INFO RFC would say "follow the rules of
> UPDATE" we would not have this problem, since the UPDATE spec
> specifically allows the use of the method before the INVITE has
> finished.
> 
> Thanks!
> 
> Christer Holmberg
> Ericsson Finland


 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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