Subject: [Sip] RE: Defining new requests
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Gonzalo Camarillo (JO/LMF)" <[email-masked]>, sip <[email-masked]>
Cc: Rohan Mahy <[email-masked]>, Dean Willis <[email-masked]>
Date: Fri, 20 Feb 2004 12:40:21 +0100
List-Id: Session Initiation Protocol <sip.ietf.org>

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip