[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Changing <unicast-address> in "o=" field
From:       Paul Kyzivat <pkyzivat () alum ! mit ! edu>
Date:       2017-11-20 17:42:02
Message-ID: d46dea3d-78eb-186c-3d5a-88510c0bf1f0 () alum ! mit ! edu
[Download RAW message or body]

On 11/20/17 5:27 AM, wisniawy wrote:
> Hello
> My Application Server sends a re-INVITE to the called party pointing in the SDP a \
> Media Server instead of calling party IP address (included in original INVITE). 
> INVITE:
> o=BroadWorks 204147 1 IN IP4 10.8.91.9
> 
> re-INVITE:
> o=BroadWorks 204150 1 IN IP4 10.8.92.133
> 
> The re-INVITE is dropped by Mobile Switching Station (MSS) because the \
> session-version ("1") of the new SDP offer is identical to the previous one. My \
> question is if the MSS behaviour is correct? In my oppinion, as the \
> <unicast-address> has changed, the session should be treated as a new one not as a \
> modification of the old one.

The new offer is incorrect based on the following text from RFC3264:

    When issuing an offer that modifies the session,
    the "o=" line of the new SDP MUST be identical to that in the
    previous SDP, except that the version in the origin field MUST
    increment by one from the previous SDP.  If the version in the origin
    line does not increment, the SDP MUST be identical to the SDP with
    that version number.

Exactly what the recipient should do when this is violated is undefined. 
IIUC it is pretty typical to ignore the violation. But an implementation 
is justified in refusing it.

	Thanks,
	Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


[prev in list] [next in list] [prev in thread] [next in thread]