On Thu, 26 Jun 2014 11:27:11 +0200, Eeri Kask wrote:
>> On Jun 25 16:16:33 EDT 2014, Sa?l Ibarra Corretg? wrote:
>>
>> Do you have any piece of network equipment which could
>> be mangling SIP packets in the path?
>>
> [...]
>
> Looking at the SIP-signaling (I have both, outgoing and
> incoming SIP-messages at both endpoints, so its easy to see
> what got changed underways) which goes through the sip-provider
> 22.22.22.22, I observe nothing mangled. The sip-provider only
> rewrites the <Contact:> fields of outgoing and incoming
> requests/replies (replaces 192.168.0.100 with 11.11.11.11,
> and back) which makes sense. (On 192.168.0.200 pjsua by
> itself inserts <Contact:> which points to 11.11.11.11 so no
> rewrite is necessary/done by sip-provider.)
>
> The spoken UPDATE message arrives at 200 as it was sent from 100
> (as said, only the <Contact:> field was replaced at sip-provider);
> so if there is anything wrong with the SDP part in it, its the
> responsibility of pjsua at 100 for this. (I tend to think pjsua
> at 100 sends a correct SDP, i.e. it seems to make sense.)
Having studied "verify_ice_sdp()" in transport_ice.c and revised the
investigations I have to withdraw most of the above statements. :-)
It looks like pjsua checks the validity of the link offer in the spoken
arrived UPDATE by constructing a remote-address (IP:port) using
m=audio 4024 RTP/AVP
c=IN IP4 192.168.0.100
and compares them with entries found in "a=candidate:...".
None of them match and so we end up with "a=ice-mismatch".
Then, again doublechecking the log's in fact it appears the sender
actually sent
m=audio 4007 RTP/AVP
c=IN IP4 192.168.0.100
(which I unfortunately initially overlooked) so along the way the port
4007 got replaced by 4024 (otherwise leading to "ice-success" above).
The sip-provider "mangles" the above m= and c= during the initial INVITE
request/response and attempts to reroute the stream through its own
relay (according to inserted IP's, port numbers), so the first thought
is they are inbetween now as well, but there is no proof.
(In the end there seems no wrongdoing whatsoever regarding pjsip; simply
to keep the successfully established nominated link up is probably the
best approach indeed.)
Eeri Kask
