[SIP SIMPLE client] [Blink] beginner SylkServer hiccups

Jeff Pyle jpyle at fidelityvoice.com
Tue Apr 26 15:39:47 CEST 2011


Hi Saúl,

SylkServer has its defaults of MSRP over TCP.  The Blink account used to
connect to it has only had its defaults modified to set the same, MSRP
over TCP instead of the default of TLS.  And MWI subscription has been
disabled.

In these logs the local Blink UA is 172.16.3.127 (although for some reason
it picks up the 192.168.1.198 IP of another interface in some places),
Opensips is 172.16.3.61:5060 and SylkServer is 172.16.3.61:5080.  In the
instances where the public IP of the SylkServer box appears in the logs,
I've regex'd that to 64.64.64.64.

You can see in this scenario where the call connects with 200 OK.  The
only indication I receive of that connection in the Blink conference
window is the Record button in the toolbar becomes available.  The status
is still "Connecting..." and the circle icon is still spinning in the
bottom area.  After a period Blink sends the BYE and disconnects the call.
 I suspect this is because it never is able to set up its MSRP session.

The root cause of the MSRP session failure is the incorrect IP SylkServer
inserts into the SDP of the 200 OK referencing the MSRP URI:
  a=path:msrp://64.64.64.64:49361/8667e4f3de773fe54c7d;tcp

Shouldn't it read something like this, spawning a process to use the
private IP accordingly?
  a=path:msrp://172.16.3.61:49361/8667e4f3de773fe54c7d;tcp

SylkServer shouldn't be doing anything on the public IP of the server,
only the private 172.16.3.61.  It seems to do okay with the SIP/RTP
traffic (I do have local_ip = 172.16.3.61 in the [SIP] portion of
config.ini), but not so much with the MSRP portion.  Audio-only
conferences seem to work great.  Audio+Chat conferences that elect MSRP
over TLS, and therefore fail to set up the Chat portion, still work over
audio with the participant window correctly populated.

I think I'm close.  How might I get SylkServer to use the correct IP in
the MSRP portion?


- Jeff


On 4/26/11 3:18 AM, "Saúl Ibarra Corretgé" <saul at ag-projects.com> wrote:

>
>
>> Referring to the first posting quoted belowŠ The presence or absence of
>> audio didn't have anything to do with the transport of the SIP packets,
>> but rather the tls or tcp setting of the MSRP Transport in Blink. A
>> setting of tcp causes an msrp:// URI in Blink's INVITE, and a
>> corresponding msrp:// URI in SylkServer's 200 OK. A setting of tls
>> causes msrps:// URIs in both cases. This makes sense. What does not make
>> sense is in the tcp case, the URI from SylkServer contained the box's
>> public IP (the wrong interface), while in the tls case the URI contained
>> the (private) IP of the Blink client. In effect it mirrored the URI of
>> the INVITE. Or, does this make sense and I'm simply not aware of the
>> underlying logic?
>>
>
>I don't I fully understand what you mean here, can you provide a SIP
>trace please?
>
>> In both cases the c= line was correct for the private IP of the
>> corresponding UA, yet Blink only recognized the audio when the MSRP
>> transport was set to tls. I verified the IP addresses and ports of the
>> RTP and RTCP packets were as described in the INVITE and 200 OK. This
>> one doesn't make sense to me either.
>>
>
>So when trying to use TCP (for MSRP) the session is stablished at the
>SIP level but then is terminated? Please enable notification trace for
>this scenario.
>
>> Even when the tcp setting was used in Blink, and the URI contained the
>> public IP of the SylkServer on port 2855, I still didn't see the
>> SylkServer machine listening on any interface on port 2855.
>>
>
>SylkServer doesn't need to listen there, a new listener is spawned when
>an incoming connection is received.
>
>
>Regards,
>
>-- 
>Saúl Ibarra Corretgé
>AG Projects

-------------- next part --------------
A non-text attachment was scrubbed...
Name: blinktraces.zip
Type: application/zip
Size: 6513 bytes
Desc: blinktraces.zip
URL: <http://lists.ag-projects.com/pipermail/sipbeyondvoip/attachments/20110426/fd9e3c77/attachment-0003.zip>


More information about the SIPBeyondVoIP mailing list