Re-Invite getting responded back as 488 Not Acceptable Media

[jayes...@gmail.com]

Hi,
I recently moved to sip.js for for my WebRTC based app, and I must admit that its pretty neat. All the functions work as expected. I am using freeswitch as my media server with webrtc capabilities enabled in it. sip.js gets connected to oversip as outbound proxy.
While the call is going on and if it needs to be put on hold, I actually initiate the command on freeswitch to place the call on hold. This causes freeswitch to generate a reinvite towards the sip.js client to which sip.js responds back as 488 Unacceptable Media and the Warning Header as "Cannot update media description".

Although the call keeps running fine, just that I dont get to hear the music on hold that freeswitch was supposed to send to the client !! Can somebody help me understand what is wrong with the freeswitch reinvite !!

The Console logs are as follows:

INVITE sip:fhig...@tsokr47gde96.invalid;transport=ws SIP/2.0
Record-Route: <sip:203.153.53.157;lr>
Via: SIP/2.0/WS 203.153.53.157:10080;branch=z9hG4bKc48f73ee4cba8401648604905010e2a7b7f6efc8;rport
Via: SIP/2.0/UDP 203.153.53.157:5060;branch=z9hG4bK4d43.85414ab4.0
Via: SIP/2.0/UDP 203.153.53.157:5000;received=203.153.53.157;rport=5000;branch=z9hG4bKgca4KvSaDQc2g
Max-Forwards: 10
From: "" <sip:00000...@203.153.53.157>;tag=SBHy9j4HNDa6D
To: <sip:50...@203.153.53.157:5060>;tag=90trarat85
Call-ID: 270f06e4-8607-1232-42b9-0022196d636d
CSeq: 62338246 INVITE
Contact: <sip:mod_...@203.153.53.157:5000>
User-Agent: CloudPBX Media Server
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 918
X-Call-Type: Agent
X-Agent-Domain: novanet.net
X-Outbound: Outbound
X-Fs-Support: update_display,send_info
P-Asserted-Identity: <sip:00000...@203.153.53.157>

v=0
o=FreeSWITCH 1405302586 1405302588 IN IP4 203.153.53.157
s=FreeSWITCH
c=IN IP4 203.153.53.157
t=0 0
a=msid-semantic: WMS MAZuusOGyHms64ppjkbdHEg8SGSlH8Kj
m=audio 46032 RTP/SAVPF 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendonly
a=silenceSupp:off - - - -
a=ptime:20
a=fingerprint:sha-256 78:5E:DE:C2:06:30:4B:69:21:81:D3:7E:99:56:31:63:DD:6C:D9:41:CE:55:DB:EC:46:12:03:9D:EE:38:93:0E
a=rtcp-mux
a=rtcp:46032 IN IP4 203.153.53.157
a=ssrc:3889894362 cname:yzETSipgQBzMwP2G
a=ssrc:3889894362 msid:MAZuusOGyHms64ppjkbdHEg8SGSlH8Kj a0
a=ssrc:3889894362 mslabel:MAZuusOGyHms64ppjkbdHEg8SGSlH8Kj
a=ssrc:3889894362 label:MAZuusOGyHms64ppjkbdHEg8SGSlH8Kja0
a=ice-ufrag:Z3JxyQvgmerUc14B
a=ice-pwd:ryk9Gzgm1GZolRUaLty9aTfm
a=candidate:5207153890 1 udp 659136 203.153.53.157 46032 typ host generation 0
a=candidate:5207153890 2 udp 659134 203.153.53.157 46032 typ host generation 0

sip-0.6.0.js:639
Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.ua | emitting event newTransaction sip-0.6.0.js:639
Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transport | sending WebSocket message:

SIP/2.0 100 Trying
Via: SIP/2.0/WS 203.153.53.157:10080;branch=z9hG4bKc48f73ee4cba8401648604905010e2a7b7f6efc8;rport
Via: SIP/2.0/UDP 203.153.53.157:5060;branch=z9hG4bK4d43.85414ab4.0
Via: SIP/2.0/UDP 203.153.53.157:5000;received=203.153.53.157;rport=5000;branch=z9hG4bKgca4KvSaDQc2g
To: <sip:50...@203.153.53.157:5060>;tag=90trarat85
From: "" <sip:00000...@203.153.53.157>;tag=SBHy9j4HNDa6D
Call-ID: 270f06e4-8607-1232-42b9-0022196d636d
CSeq: 62338246 INVITE
Supported: outbound
Content-Length: 0

sip-0.6.0.js:639
Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transaction.ist | adding event stateChanged sip-0.6.0.js:639
Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transaction.ist | new listener added to event stateChanged sip-0.6.0.js:639
Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transaction.ist | new listener added to event stateChanged sip-0.6.0.js:639
Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.inviteservercontext | re-INVITE received sip-0.6.0.js:639
Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transport | sending WebSocket message:

SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS 203.153.53.157:10080;branch=z9hG4bKc48f73ee4cba8401648604905010e2a7b7f6efc8;rport
Via: SIP/2.0/UDP 203.153.53.157:5060;branch=z9hG4bK4d43.85414ab4.0
Via: SIP/2.0/UDP 203.153.53.157:5000;received=203.153.53.157;rport=5000;branch=z9hG4bKgca4KvSaDQc2g
To: <sip:50...@203.153.53.157:5060>;tag=90trarat85
From: "" <sip:00000...@203.153.53.157>;tag=SBHy9j4HNDa6D
Call-ID: 270f06e4-8607-1232-42b9-0022196d636d
CSeq: 62338246 INVITE
Warning: Cannot update media description
Supported: outbound
Content-Length: 0

[Joseph Frazier]

Hi Jayesh,

Thanks for using SIP.js, I'm glad to hear you like it!

Supporting re-invites is currently not implemented, due to difficulties with renegotiating the media description of the browser's PeerConnection. You can take a look at Github issue 19 for more detail. If you can configure Freeswitch to play the hold music without re-inviting the SIP.js endpoint, it should work. For example, this happens automatically when FS is bridging a call and one endpoint puts the other on hold.

Cheers,

Joseph

On Monday, July 14, 2014 12:21:08 PM UTC-4, jayes...@gmail.com wrote:

Hi,
I recently moved to sip.js for for my WebRTC based app, and I must admit that its pretty neat. All the functions work as expected. I am using freeswitch as my media server with webrtc capabilities enabled in it. sip.js gets connected to oversip as outbound proxy.
While the call is going on and if it needs to be put on hold, I actually initiate the command on freeswitch to place the call on hold. This causes freeswitch to generate a reinvite towards the sip.js client to which sip.js responds back as 488 Unacceptable Media and the Warning Header as "Cannot update media description".

Although the call keeps running fine, just that I dont get to hear the music on hold that freeswitch was supposed to send to the client !! Can somebody help me understand what is wrong with the freeswitch reinvite !!

The Console logs are as follows:

INVITE sip:fhig86aa@tsokr47gde96.invalid;transport=ws SIP/2.0

[jayes...@gmail.com]

On Monday, July 14, 2014 10:25:55 PM UTC+5:30, Joseph Frazier wrote:
> Hi Jayesh,
>
>
> Thanks for using SIP.js, I'm glad to hear you like it!
>
>
> Supporting re-invites is currently not implemented, due to difficulties with renegotiating the media description of the browser's PeerConnection. You can take a look at Github issue 19 for more detail. If you can configure Freeswitch to play the hold music without re-inviting the SIP.js endpoint, it should work. For example, this happens automatically when FS is bridging a call and one endpoint puts the other on hold.
>
>
> Cheers,
> Joseph
>
> On Monday, July 14, 2014 12:21:08 PM UTC-4, jayes...@gmail.com wrote:Hi,
> I recently moved to sip.js for for my WebRTC based app, and I must admit that its pretty neat. All the functions work as expected. I am using freeswitch as my media server with webrtc capabilities enabled in it. sip.js gets connected to oversip as outbound proxy.
> While the call is going on and if it needs to be put on hold, I actually initiate the command on freeswitch to place the call on hold. This causes freeswitch to generate a reinvite towards the sip.js client to which sip.js responds back as 488 Unacceptable Media and the Warning Header as "Cannot update media description".
> Although the call keeps running fine, just that I dont get to hear the music on hold that freeswitch was supposed to send to the client !! Can somebody help me understand what is wrong with the freeswitch reinvite !!
>
> The Console logs are as follows:

> INVITE sip:fhig...@tsokr47gde96.invalid;transport=ws SIP/2.0

> Record-Route: <sip:203.153.53.157;lr>
> Via: SIP/2.0/WS 203.153.53.157:10080;branch=z9hG4bKc48f73ee4cba8401648604905010e2a7b7f6efc8;rport
> Via: SIP/2.0/UDP 203.153.53.157:5060;branch=z9hG4bK4d43.85414ab4.0
> Via: SIP/2.0/UDP 203.153.53.157:5000;received=203.153.53.157;rport=5000;branch=z9hG4bKgca4KvSaDQc2g
> Max-Forwards: 10

> From: "" <sip:000...@203.153.53.157>;tag=SBHy9j4HNDa6D

> To: <sip:50...@203.153.53.157:5060>;tag=90trarat85
> Call-ID: 270f06e4-8607-1232-42b9-0022196d636d
> CSeq: 62338246 INVITE
> Contact: <sip:mod_...@203.153.53.157:5000>
> User-Agent: CloudPBX Media Server
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
> Supported: timer, path, replaces
> Privacy: none
> Content-Type: application/sdp
> Content-Disposition: session
> Content-Length: 918
> X-Call-Type: Agent
> X-Agent-Domain: novanet.net
> X-Outbound: Outbound
> X-Fs-Support: update_display,send_info

> P-Asserted-Identity: <sip:000...@203.153.53.157>

> From: "" <sip:000...@203.153.53.157>;tag=SBHy9j4HNDa6D

> Call-ID: 270f06e4-8607-1232-42b9-0022196d636d
> CSeq: 62338246 INVITE
> Supported: outbound
> Content-Length: 0
>
>  sip-0.6.0.js:639
> Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transaction.ist | adding event stateChanged sip-0.6.0.js:639
> Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transaction.ist | new listener added to event stateChanged sip-0.6.0.js:639
> Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transaction.ist | new listener added to event stateChanged sip-0.6.0.js:639
> Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.inviteservercontext | re-INVITE received sip-0.6.0.js:639
> Mon Jul 14 2014 20:13:25 GMT+0530 (IST) | sip.transport | sending WebSocket message:
> SIP/2.0 488 Not Acceptable Here
> Via: SIP/2.0/WS 203.153.53.157:10080;branch=z9hG4bKc48f73ee4cba8401648604905010e2a7b7f6efc8;rport
> Via: SIP/2.0/UDP 203.153.53.157:5060;branch=z9hG4bK4d43.85414ab4.0
> Via: SIP/2.0/UDP 203.153.53.157:5000;received=203.153.53.157;rport=5000;branch=z9hG4bKgca4KvSaDQc2g
> To: <sip:50...@203.153.53.157:5060>;tag=90trarat85

> From: "" <sip:000...@203.153.53.157>;tag=SBHy9j4HNDa6D

> Call-ID: 270f06e4-8607-1232-42b9-0022196d636d
> CSeq: 62338246 INVITE
> Warning: Cannot update media description
> Supported: outbound
> Content-Length: 0

Thank you for the reply Joseph. Issue #19 explains the whole thing well. So till the time peer connection doesn't allow us to update media, this is the only way ahead.

Thanks again.