On 10/9/12 1:44 PM, [email protected] wrote:
> Hello Guys,
>
> Different SDP in 183 and 200_OK is a protocol violation or implementation 
> dependent?
>
> I am seeing some previous discussions on this topic, but the answers are not 
> quite convincing to me. I am unable to find SIP RFCs to see how this scenario 
> is handled.
>
> 1)SIP-Server sends a SIP INVITE(offer) to SIP-SS7-Gateway
> 2)SIP-SS7-Gateway converts a SIP INVITE to IAM and sends IAM out
> 3)SIP-SS7-Gateway receives ACM (Lets say the far SS7 end opens up voice path 
> upon ACM rather than ANM, may be a kind of announcement server. I guess, i 
> can calls this Early-Media)
> 4)SIP-SS8-Gateway converts ACM into 183 sends 183(answer) to SIP-Server
> 5)SIP-Server sends back PRACK to SIP-SS7-Gateway

So the 183 was a reliable provisional response.

> 6)SIP-SS7-Gateway sends 200 OK (PRACK) to SIP-Server
> 7)SIP-SS7-Gateway receives ANM (from SS7 network perspective, the CIC is same 
> for this call, so opening voice path after ACM or ANM makes no difference)
> 8)SIP-SS7-Gateway converts ANM into 200_OK and sends 200_OK(different answer) 
> to SIP-Server

There are two things that are legal to send in the 200 INVITE:

- no SDP. This is preferred. The O/A was completed by the reliable 183.

- the *same* SDP that was sent in the reliable provisional.
   This is legal because of how 3261 is worded.

It is *not* legal to send *different* SDP in the 200 in this case.
BUT 3261 says it is to be ignored, so it may not be detected as a problem.

There is nothing written that says or implies that you may send two 
different answers to the same offer and have them both acted on.

(I'm assuming all the messages above have the same from- and to-tags. If 
that is not so then it gets more complicated.)

You should take a look at RFC 6337.

        Thanks,
        Paul

> ...
>
>
> In the step8, SIP-SS8-Gateway sends a different answer in the 200 OK for some 
> internal reason (implementation dependent ,may be to intercept only the 
> user's voice or etc...)
>
> PS: Please do not quote the section 13.2.1 in rfc 3261.
>
> Thanks
> Sam J
> ________________________________
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to