Subject: [Sip] Defining new requests

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Feb 2004 13:21:24 +0200

Folks,

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)."

Regards,

Gonzalo

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 20 Feb 2004 13:06:23 +0100

I don't know how happy it would be, but at least it wouldn't have to spend time on this relatively minor issue :)

Regards,

Christer

> -----Original Message-----
> From: Gonzalo Camarillo (JO/LMF) 
> Sent: 20. helmikuuta 2004 13:55
> To: Christer Holmberg (JO/LMF)
> Cc: sip; Rohan Mahy; Dean Willis
> Subject: Re: Defining new requests
> 
> 
> 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):
> >>
> >>final response instead, to terminate the dialog, people assume that
> > 
> > INFO 
> > 
> >>Let's try to keep this in mind and clarify this point when/if 
> >>we define new SIP methods.
> >>
> >>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
> 
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sun, 22 Feb 2004 23:16:29 -0000

While RFC 3398 may appear to clarify this, it is not in the scope of RFC 3398 to do so.

RFC 3398 defines only the interworking, not the SIP protocol associated with it.

I would suggest a bug fix is tables for the INFO RFC.

regards

Keith

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]]
> Sent: 20 February 2004 11:40
> To: Gonzalo Camarillo (JO/LMF); sip
> Cc: Rohan Mahy; Dean Willis
> Subject: [Sip] RE: Defining new requests
> 
> 
> 
> Hi Gonzalo,
> 
> Thanks for your reply!
> 
> >figuring out whether or not certain requests can be sent by 
> the UAS within an 
> 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.
> 
>