Subject: Re: [Sip] Re: INFO Documentation (was Re: Defining new requests)

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Feb 2004 14:41:49 +0200

Keith,

> This is an revision requirement to INFO, not to an interworking
> specification, so it should be in SIP, not in SIPPING. It is the core
> INFO RFC that is itself not complete enough in this area.

we are already discussing this in *SIP*, not in *SIPPING*. What I am 
missing from your comment?

Thanks,

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: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Feb 2004 14:44:20 +0200

Keith,

OK, I re-read the thread and I have noticed that you were referencing my 
last email. What I actually meant was that we should see whether we 
deprecate INFO so that it only transports PSTN stuff, or, on the other 
hand, we define INFO packages. We had some discussions about that some 
time ago.

So, we need to discuss which requirements we need to fulfill, and that 
should be done in SIPPING. The actual document updating INFO will be 
done in SIP, as you suggest.

Thanks,

Gonzalo

Drage, Keith (Keith) wrote:

> This is an revision requirement to INFO, not to an interworking specification, so it should be in SIP, not in SIPPING. It is the core INFO RFC that is itself not complete enough in this area.
> 
> Note that part of that revision should also be to update the RFC 2543 references to RFC 3261.
> 
> regards
> 
> Keith
> 
> 
>>-----Original Message-----
>>From: Gonzalo Camarillo [mailto:[email-masked]]
>>Sent: 26 February 2004 12:26
>>To: Tom Taylor
>>Cc: Christer Holmberg (JO/LMF); sip; Rohan Mahy; Dean Willis
>>Subject: [Sip] Re: INFO Documentation (was Re: Defining new requests)
>>
>>
>>Tom.
>>
>>it seems that what you want is an update of the INFO spec, 
>>rather than 
>>fixing a few errata. I believe that we cannot meet your timeframe. In 
>>any event, it would be great we could start working on a solution for 
>>INFO in SIPPING, so that the ITU could reference it in the future.
>>
>>Thanks,
>>
>>Gonzalo
>>
>>Tom Taylor wrote:
>>
>>
>>>Q.1912.5 is in the process of final approval.  Logging 
>>
>>errata may be 
>>
>>>satisfactory -- I'd have to check.  It would certainly be more 
>>>comfortable than reproducing the RFC with modifications in the ITU 
>>>document.  If the IETF acts within the next two weeks we 
>>
>>should be able 
>>
>>>to remove the Annex from the Recommendation.
>>>
>>>Here is the current list of changes as reported at the 
>>
>>beginning of the 
>>
>>>Annex.
>>>
>>>"The SIP INFO method is documented in RFC 2976. However, 
>>
>>that RFC refers 
>>
>>>to RFC 2543, the previous version of the SIP specification, 
>>
>>rather than 
>>
>>>to RFC 3261. The text of this Annex reproduces RFC 2976 
>>
>>with changes to 
>>
>>>reflect the updated reference.
>>>
>>>"The changes made are as follows:
>>>
>>>"Paragraph C.3.2.1: The references to the tables of RFC2543 
>>
>>were changed 
>>
>>>to reflect the new table organization in RFC 3261.
>>>
>>>"Paragraph C.3.2: The tables 1 and 2 were replaced by new 
>>
>>tables that 
>>
>>>show the header fields defined as presented in RFC3261. All 
>>
>>additional 
>>
>>>headers (additional to RFC 2543) used within RFC3261 were 
>>
>>here set to 
>>
>>>optional with two exceptions. The Reply-To (only optional for the 
>>>INVITE) and Call-Info Header (only used for INVITE, 
>>
>>OPTIONS, REGISTER to 
>>
>>>give additional information about the caller or callee) are 
>>
>>not used 
>>
>>>with the INFO method.
>>>
>>>"Paragraph C.3.6: The reference was changed to the current SIP 
>>>specification, RFC 3261.
>>>
>>>
>>>Gonzalo Camarillo wrote:
>>>
>>>
>>>>Tom,
>>>>
>>>>what is the timeframe here? As you know, we have had 
>>
>>discussions in 
>>
>>>>the past about either re-defining INFO so that it can only 
>>
>>carry PSTN 
>>
>>>>telephony signalling, or defining INFO packages. We could re-start 
>>>>those discussions, and once we reach a conclusion, clarify 
>>
>>the rules 
>>
>>>>to send INFO from the UAS within early dialogs in the same spec...
>>>>
>>>>If the ITU is in a hurry, other solutions may be better, 
>>
>>like logging 
>>
>>>>an errata against the INFO RFC.
>>>>
>>>>Gonzalo
>>>>
>>>>Tom Taylor wrote:
>>>>
>>>>
>>>>>The ITU-T (Study Group 11, to be exact) had a different 
>>
>>issue with 
>>
>>>>>INFO: that the RFC depends on RFC 2543 rather than 3261.  As a 
>>>>>result, they picked up the content of RFC 2976 as Annex 
>>
>>C.3 of the 
>>
>>>>>ISUP interworking specification Q.1912.5.  If RFC 2976 ever gets 
>>>>>updated Annex C.3 can be deprecated.  In the meantime, this INFO 
>>>>>question means we have some maintenance to perform.  I 
>>
>>think the best 
>>
>>>>>solution will be to take Gonzalo's suggestion and say that INFO 
>>>>>follows the rules for UPDATE.  We already have a 
>>
>>normative dependency 
>>
>>>>>on the UPDATE RFC.
>>>>>
>>>>>Gonzalo Camarillo wrote:
>>>>>
>>>>>
>>>>>>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.
>>>>
>>>>
>>
>>-- 
>>Gonzalo Camarillo         Phone :  +358  9 299 33 71
>>Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
>>Telecom R&D               Fax   :  +358  9 299 30 52
>>FIN-02420 Jorvas          Email :  [email-masked]
>>Finland                   http://www.hut.fi/~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.
>>
>>

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 Feb 2004 17:43:31 -0500

At least one possible use case is for location updates during emergency 
calls. I'll discuss this option during the relevant SIPPING segment. (At 
this point, I'm not arguing that this is how it should be done, just 
that it as a plausible option.)