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]

 



Paul and Christer,

IMHO, I don't like the first-reliable-provisional-resp-with-sdp rule.
Implementation are required to accept first reliable response without
sdp by customer,
While must be prepared to follow this rule sending resp in case any
criticism of non-compliance from other vendors,
Which makes implemenation more complex.

BTW, what's the history on making this rule,could you please share with
me?

Thanks
Regards,
-Rockson
-----Original Message-----
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On
Behalf Of Paul Kyzivat (pkyzivat)
Sent: Tuesday, March 31, 2009 4:55 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.)

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

	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