[Spce-user] Ring back problem with a peer

[Jon Bonilla (Manwe)]

El Mon, 25 Feb 2013 19:17:17 +0000
Paul Cupis <paul at cupis.co.uk> escribió:

> On 25/02/13 15:11, Pablo Muñoz-Cobo wrote:
> > This is what the my peer support team states about their softswitch
> > behaviour (GSX).
> >
> > the issue is on the egress IP peer(spce). They do send 180 Ringing with
> > SDP, but no RTP media packets with RBT. You need to ask them to do
> > either of these 2 things:
> >
> > 1) Send RTP media packets with the RBT. The egress peer does send SDP in
> > 180 Ringing, so the GSX is expecting RPT which he would pass to the
> > ingress peer.
> >
> > 2) Do not send SDP in the 180 Ringing. This, if configured on the GSX,
> > will make the GSX to generate LRBT and send it to the ingress.
> >
> > Any help to perform what they say or any argument to fight back their
> > statement. Thanks a lot for help!!
> 
> I can't help with the SPCE side of things, but their statement is 
> reasonable - 180 w/SDP implies you will send them early media (RBT). 183 
> w/SDP would be better/more explicit for this scenario really.
> 
> If you are not going to be sending them early media, you should be 
> sending them 180 w/o SDP.
> 

Hi Pablo and Paul

I've been exchanging a couple of mails with Pablo in private. I wanted to solve
the iisue, which in my opinion, is a peer issue before coming back to the
thread.

Paul, I think that 180 with SDP is valid. The only restriction is that the
final response (200) MUST include the same SDP. It helps with faster session
negotiation but has nothing to do with early media or sending RTP. It just
tells the other side to generate the ringing tone. 

183 is what you would send for early media with rtp but it's perfectly valid
(and common) to send 180 with sdp. Please check RFC 3261 chapter 13.2.1

" If the initial offer is in an INVITE, the answer MUST be in a
   reliable non-failure message from UAS back to UAC which is
   correlated to that INVITE.  For this specification, that is
   only the final 2xx response to that INVITE.  That same exact
   answer MAY also be placed in any provisional responses sent
   prior to the answer.  The UAC MUST treat the first session
   description it receives as the answer, and MUST ignore any
   session descriptions in subsequent responses to the initial
   INVITE. "

Anyways, the spce does not generate the 180. It just relays the 180 generated
by the UA. I guess that a custom template could identify the response and
delete the body from it, so technically is possible but the problem here is in
the peer. 

Please Pablo, keep us informed. I'd like also to know which peer and which
user-agent they are using. And why is it different for mobile and fixed line
scenarios? I guess they have a problem in one of their carrier routes.


cheers,

Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130226/50aa3798/attachment-0001.asc>