Krom

Thanks - I will be taking this off-line to support@. Net - the service with Verizon requires an IKE negotiated tunnel between the two networks. So, for "testing" you will need to be on our network..... - Krom

Yes - you will need to setup wholesale services with Verizon. They have recently deployed the CS2000 in new markets on the UUNet/MCI network. Can you confirm that PBXnSIP is supporting RFC 3407?

We are experiencing failed calls when interacting with a certain upstream GW. Nortels CS2000 is responding to INVITES with a 183 with an SDP that is either to a new standard release or not supported by PBXnSIP. Here is the following and please help me understand my course of action. PBXnSIP <--> Ditech C100 SBC <--> Nortel CS2000 PBXnSIP INVITE with the following SDP payload. User-Agent: pbxnsip-PBX/2.0.3.1715 v=0 o=- 25385 25385 IN IP4 10.x.x.x s=- c=IN IP4 10.x.x.x t=0 0 m=audio 55350 RTP/AVP 0 8 2 3 101 a=fmtp:101 0-11 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv CS200 responds with 183 Session Progress with the following SDP payload. Server: CS2000_NGSS/8.0 v=0 o=PVG 0 841331007 IN IP4 x.x.x.x s=- p=+1 6135555555 c=IN IP4 x.x.x.x t=0 0 a=cdsc: 1 audio RTP/AVP 0 8 116 18 13 101 a=cpar: a=rtpmap:116 AAL2-G726-32/8000 a=cpar: a=rtpmap:101 telephone-event/8000 a=cpar: a=fmtp:101 0-15 a=cpar: a=ptime:10 a=cpar: a=ptime:20 a=cpar: a=fmtp:18 annexb=yes a=sqn: 0 m=audio 57802 RTP/AVP 0 8 101 a=fmtp:101 0-15 a=ptime:20 a=rtpmap:101 telephone-event/8000 Then PBXnSIP responds with a CANCEL I see some problems with compatibility of the SDP payloads and I am reaching out for assistance in resolution. In the list of RTP/AVP from the CS2000 CODECs 0 and 8 (which are in the PBXnSIP INVITE = match) are listed but with no corresponding a= parameter. Seems out of standard. Does PBXnSIP support RFC 3407? Thanks for any assistance. -Krom

I am just joining the PBXnSIP community and have the same question as jholland posted back in March. In our hosted environment we are seeing that about 40% of our calls are intercom calls or supervised transfers and would like to keep the local LAN (intercom) calls RTP media local with RE-INVITEs after the PBXnSIP has handled the call signaling to the registered end point. This would save of the bandwidth requirements between the hosted site and the remote location. It should also be the method for any group paging feature. We are using OpenSER as the front end proxy between the remote location end points and PBXnSIP. The end points of course are registering with PBXnSIP and not OpenSER so I would be looking for a solution within PBXnSIP to support RE-INVITEs between end points registering from the same remote locations. Again, I am new to PBXnSIP so please forgive any ignorance. But I have abandoned all hope for * in a hosted environment. SIP stack blows.... Krom