A short introduction to the problem follows. In SIP protocol the typical call establishment is done in a three way handshake transmission.
A -> INVITE -> B
A < - OK <- B
A -> ACK -> B
The INVITE and OK messages must contain SDP data to specify session parameters such as ports for RTP streaming and supported codecs. So basically in INVITE message party A specifies its supported resources and network endpoints which will receive media traffic from B. In the same way party B specifies its supported resources and endpoints in OK message.
The problem raised when I was trying to figure out why RTP traffic is not transmitted by RFC 3261 compliant user agents when call seemed to be established.
I finally realized that RFC compliant user agent would not use IP address specified in the ORIGIN header for media streams and in my SIP application I simply did not use SDP connection headers for session or media descriptors. I mistakenly thought that ORIGIN address can be used when no other is specified.
It is a requirement by RFC 3261 that session address must be included in session connection header or in the media connection header of the SDP message. I wonder why then the address is needed for origin header as this header serves only as a identifier for the session.
The correct SDP packet with connection headers would look like this:
v=0 o=- 1162821101 1162821101 IN IP4 192.168.255.11 s=session t=0 0 m=audio 7332 RTP/AVP 8 0 3 97 101 c=IN IP4 192.168.255.11 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:101 telephone-event/8000 m=video 0 RTP/AVP 31 34 c=IN IP4 192.168.255.11 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000
Surprisingly, when this rule is not followed the call will be established successfully but no media traffic is transmitted and no any error messages can be signalled because session establishment is a different layer in SIP architecture.