Help! invite forward to nonoh.net

[Noodle]

Hi Forum,

I'm having an issue with forward invite to nonoh.net.

The request and response without forward is:
INVITE to Nonoh.net
Response 100 from nonoh.net
response 183 (session in progress) with SDP from nonoh.net
after few seconds, response 183 with updated SDP from nonoh.net

During 183 response from nonoh.net, it contains SDP, and will send
ring in media channel, never get 180 (ringing) from nonoh.net.

Now, with sip servlet in middle:
INVITE to sip servlet
sip servlet forward INVITE to nonoh.net
nonoh.net response 183 with SDP
forward 183 with SDP to client
after few seconds, response 183 with updated SDP from nonoh.net
BUT sip servlet will
org.mobicents.servlet.sip.core.dispatchers.ResponseDispatcher -
retransmission received for a non proxy application, dropping the
response

So, without correct SDP, client never hear rington.

I know nonoh.net isn't follow spec exactly, but nonoh.net probably can
support customized rington in this way. How can I deal with it?

Thanks

NBoodle

[Noodle]

SipServlet spec didn't mention how to treat 183, RFC 3261 didn't say
183 need to treat special either. But in "Understand SIP", page 113:
5.1.5 183 Session Progress
The 183 Session Progress response indicates that information about the
prog- ress of the session (call state) may be present in a message
body or media stream. Unlike a 100 Trying response, a 183 is an end-to-
end response and establishes a dialog (must contain a To tag and
Contact). Unlike a 180, 181, or 182 response, it does not convey any
specific information about the status of the INVITE. A typi- cal use
of this response is to allow a UAC to hear a ring tone, busy tone, or
re- corded announcement in calls through a gateway into the PSTN. This
is because call progress information is carried in the media stream in
the PSTN. A one- way media connection or trunk is established from the
calling party’s telephone switch to the called party’s telephone
switch in the PSTN prior to the call being answered. In SIP, the media
session is established after the call is answered—after a 200 OK and
ACK have been exchanged between the UAC and UAS. If a gateway uses a
180 Ringing response instead, no media path will be established
between the UAC and the gateway, and the caller will never hear a ring
tone, busy tone, or recorded announcement (e.g., “The number you have
dialed has changed, the new number is . . .”) since these are all
heard in the media path prior to the call being answered. Figure 9.1
shows an example call flow with early media.

So 183 is for customize rington. In this case, if it contains SDP,
then we should allow them to be updated. In another word, because it
will change session/dialog status, I think we can safely forward it
multiple times instead of drop retransmission. Or probably 183 is not
retransmission because it contains updated SDP information?

Thanks

Noodle

[Vladimir Ralev]

Right now there is no way to deal with this. May be we should not recognize the second 183 as retransmissions if it has different SDP.

I need to check something but afaik this is a valid use-case, because sometimes you dial, you get ringback tone with 183, but if nobody picks in 30-40 seconds you would get another tone again with 183.

It is easy to fix if we keep the last response to compare. We used to keep it, but that was removed for optimization. We could probably store it only for 183 for very short time without increasing the memory footprint.

Feel free to open an issue and optionally provide a patch. If there is no spec that forbids it we should include this.

[Vladimir Ralev]

Created issue http://code.google.com/p/mobicents/issues/detail?id=2251

[Noodle]

Thanks the fix works.

Noodle

On Jan 2, 10:41 pm, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> Created issuehttp://code.google.com/p/mobicents/issues/detail?id=2251

>
> On Sun, Jan 2, 2011 at 4:20 AM, Vladimir Ralev <vladimir.ra...@gmail.com>wrote:
>
>
>
> > Right now there is no way to deal with this. May be we should not recognize
> > the second 183 as retransmissions if it has different SDP.
>
> > I need to check something but afaik this is a valid use-case, because
> > sometimes you dial, you get ringback tone with 183, but if nobody picks in
> > 30-40 seconds you would get another tone again with 183.
>
> > It is easy to fix if we keep the last response to compare. We used to keep
> > it, but that was removed for optimization. We could probably store it only
> > for 183 for very short time without increasing the memory footprint.
>
> > Feel free to open an issue and optionally provide a patch. If there is no
> > spec that forbids it we should include this.
>

[Tom Smith]

Sorry I'm late chiming in here. For what it's worth, I think this
behavior violates RFC 3261. From section 13.2.1:

o 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.

That being said, you still have to decide what the container should do
if it is the recipient of this non-compliant message sequence.

[Vladimir Ralev]

Good point. But that's OK. The SIP spec doesn't account for early media. IMO it's up to the app to implement the UAC behavior according to whatever spec with or without early media and is free to interpret SDP however it likes. The biggest issue I had is wether the second 183 should be regarded as retransmission or not which would violate the Sip Servlets spec.

[Jean Deruelle]

There is an ongoing thread on sip-implementors about this http://www.mail-archive.com/sip-impl...@lists.cs.columbia.edu/msg09287.html

Although it violates the offer answer model defined by RFC 3261, it is up to the application to decide what it should do with it not the container IMO.

Ultimately the app decides if it acts as a UAC, UAS, B2BUA or Proxy, the container should just pass the message as it is not a retransmission and it is targeted at an application that acted as UAC as per SIP Servlets Specification. 

So for correctness, we should let it pass but Noodle beware of this behavior...

[Tom Smith]

Interesting, thanks for the pointer.