Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Pl. see inline .. 

>-----Original Message-----
>From: sipping-bounces@xxxxxxxx 
>[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Paul Kyzivat (pkyzivat)
>Sent: Tuesday, March 31, 2009 2:25 AM
>To: Christer Holmberg
>Cc: sipping@xxxxxxxx
>Subject: Re:  PRACK: Change MUST requirement to 
>include SDP offer in first reliable provisional response
>
>
>
>Christer Holmberg wrote:
>> 
>> Hi,
>> 
>> One of the PRACK related issues presented in SFO is whether 
>we should 
>> change the requirement to include SDP offer in the first reliable 
>> provisional response, if the INVITE does not contain SDP.
>> 
>> Two use-cases, which the current requirement affect, were presented:
>> 1. H.323/SIP interworking, where an empty INVITE may have been 
>> received and an SDP offer is not available when the first 
>reliable 18x 
>> is to be sent (please see meeting slides for details).
>
>This is the issue I hear complaints about.
>
>> 2. Call fowarding, when a 181 provisional is sent. The 181 
>may be sent 
>> by an intermediate, and if the INVITE did not contain SDP a reliable 
>> 181 would be required to contain an SDP offer.
>
>This is only an issue if the INVITE contained Require:100rel. 
>(And AFAIK that is rarely the case. If it was the case the 181 
>could simply be
>omitted.)

That's true, but since 181 is a response code defined in rfc 3261, this
use case is valid when Invite has Require:100rel. And the solution
should take care of this use case.

>
>Otherwise, an unreliable 181 can be sent, which needn't have SDP.
>
>Another possibility would be to send a 181 with bogus SDP. For 
>instance it could have c=0 and port=0 for all the media. That 
>could work even reliably.

Problem is that bogus sdp interpretation varies depending on
implementation. Some use the method you describe above, some others use
media attributes, some other variations in m line.


> And it wouldn't affect any real 
>answers because it will have a unique to-tag.
>
>> It was indicated that there may be backward compability issues. That 
>> of course depends on the number of deployments where INVITE without 
>> SDP is sent AND a reliable 18x without SDP offer would cause 
>an error.
>> 
>> Some people indicated concern, so I would like to ask what 
>people think? 
>> Would changing the rules cause problems in existing deploymentnts?
>
>I'll have to ask around.

As you suggested, maybe getting some feedback from upcoming SIPIt should
also help.

Thanks

>
>	Paul
>
>> Regards,
>> Christer
>> 
>> 
>> 
>----------------------------------------------------------------------
>> --
>> 
>> _______________________________________________
>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use 
>> sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use 
>> sip@xxxxxxxx for new developments of core SIP
>_______________________________________________
>Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP Use 
>sip-implementors@xxxxxxxxxxxxxxx for questions on current sip 
>Use sip@xxxxxxxx for new developments of core SIP
>
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux