Hi Tom,
o Tom van der Geer [09/16/09 13:00]:
Hi,
Browsing through the logs of my C2D application (AmB2BSession) I've
found a situation where of the upstream proxies sent and INFO message
after a certain period to check if the session was still alive. In this
its most probably not the proxy, but the endpoint that sent the INFO.
proxies may not originate requests if i am not mistaken...
case it was received in the C2DCalleeSession. My application responded
by forwarding the INFO message to the proxy connected in the
CallerSession (relayEvent). This particular proxy did not respond to the
INFO message, so this led to a disconnect, because after 32 seconds the
again, its not the proxies' duty to respond, but the endpoint.
C2D app decided that it timed out and sent a "408 Timeout" to the proxy
connected on the CallerSession.
Is this the proper behavior? Should the INFO message be relayed?
in my opinion, if a B2BUA is in the dialog it should relay all messages
after the dialogs are created; it should do something different only if
the session is stopped (BYE and CANCEL).
The situation you describe looks to me like an endpoint problem - the
endpoint should definitely reply something to the INFO.
Nevertheless, one reason (the only?) for having a B2BUA in the middle is
to fix broken endpoint behaviour which you don't have influence over
otherwise. This road may be dangerous though: You should for example be
aware that DTMF may also be transmitted in SIP INFO (de-facto standard
even if there is RFC). If you catch the INFO in the middle, DTMF may
stop working. You may also have a look at the content-type
(application/dtmf or application/dtmf-relay), but in principle all
middle box actions may sooner or later break some new features of the
end points (see broken SIP ALG topic).
[...]
In this particular case it was probably better if the C2D application
responded with a 200 OK in stead of relaying the message. How can this
be achieved?
implement your own onSipRequest method where you catch INFO like this:
void MyCalleeSession::onSipRequest(const AmSipRequest& req)
{
if ((req.method=="INFO") &&
(req.content_type == "whatever") &&
// maybe some more checks here
) {
dlg.reply(req, 200, "OK" ["application/mycontent", "body..."]);
}
} else {
AmB2BCalleeSession::onSipRequest();
}
}
Stefan
Thanks in advance for your responses!
Best regards,
Tom
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
--
Stefan Sayer
VoIP Services
[email protected]
www.iptego.com
IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
