Hello,
I dont really understand, but :
I just need to do in the INVITE :
record_route_preset('$dd:$dp;codec=alaw');
forward();
and for the CANCEL:
if(check_route_param(";codec=alaw")){
route(2);
}
Is it possible?
Thank you
Cordialement
BERGANZ François
Hi,
I just happen to find an issue with a software trying to call through my openser-1.3.1
After inserting "a=nortpproxy:yes\r\n", the message coming out openser is:
[normal sdp packet] a=fmtp:101 0-15\r\n \r\n \r\n "a=nortpproxy:yes\r\n"
No matter who is responsible in that specific case (the SDP received by openser with several \r\n looks not compliant to me).
I think openser should add "a=nortpproxy:yes" in different place in the SDP packet: NOT at the end of the SDP body. The "a=nortpproxy:yes" should be either put at the global attribute level or right below a m= line.
This approach would solve such issue and would be much more adequate to the requirement: currently it's not very possible to relay an audio stream and not relay a video stream with the current approach.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
A similar bug was also described in opensips. They tried to fix it but the bug is still present. I wonder if this is something new or if the bug is thre since the beginning of nathelper but did not occured until now
klaus
Aymeric Moizard schrieb:
Hi,
I just happen to find an issue with a software trying to call through my openser-1.3.1
After inserting "a=nortpproxy:yes\r\n", the message coming out openser is:
[normal sdp packet] a=fmtp:101 0-15\r\n \r\n \r\n "a=nortpproxy:yes\r\n"
No matter who is responsible in that specific case (the SDP received by openser with several \r\n looks not compliant to me).
I think openser should add "a=nortpproxy:yes" in different place in the SDP packet: NOT at the end of the SDP body. The "a=nortpproxy:yes" should be either put at the global attribute level or right below a m= line.
This approach would solve such issue and would be much more adequate to the requirement: currently it's not very possible to relay an audio stream and not relay a video stream with the current approach.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
On 09/11/08 16:10, Klaus Darilion wrote:
A similar bug was also described in opensips. They tried to fix it but the bug is still present. I wonder if this is something new or if the bug is thre since the beginning of nathelper but did not occured until now
maybe this can be fixed by using the sdp parser available now in core. nathelper has quite limited sdp parsing capabilities now. the issue is to find the proper hook to add the lump with
a=nortpproxy:yes\r\n"
Cheers, Daniel
klaus
Aymeric Moizard schrieb:
Hi,
I just happen to find an issue with a software trying to call through my openser-1.3.1
After inserting "a=nortpproxy:yes\r\n", the message coming out openser is:
[normal sdp packet] a=fmtp:101 0-15\r\n \r\n \r\n "a=nortpproxy:yes\r\n"
No matter who is responsible in that specific case (the SDP received by openser with several \r\n looks not compliant to me).
I think openser should add "a=nortpproxy:yes" in different place in the SDP packet: NOT at the end of the SDP body. The "a=nortpproxy:yes" should be either put at the global attribute level or right below a m= line.
This approach would solve such issue and would be much more adequate to the requirement: currently it's not very possible to relay an audio stream and not relay a video stream with the current approach.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hi All,
Just FYI, I had to disable the nortpproxy test here because it breaks thomson ST2030 endpoints : with that line, they would just plain ignore the messages containing the SDP ...
Cheers,
On Fri, 2008-09-12 at 18:12 +0300, Daniel-Constantin Mierla wrote:
On 09/11/08 16:10, Klaus Darilion wrote:
A similar bug was also described in opensips. They tried to fix it but the bug is still present. I wonder if this is something new or if the bug is thre since the beginning of nathelper but did not occured until now
maybe this can be fixed by using the sdp parser available now in core. nathelper has quite limited sdp parsing capabilities now. the issue is to find the proper hook to add the lump with
a=nortpproxy:yes\r\n"
Cheers, Daniel
klaus
Aymeric Moizard schrieb:
Hi,
I just happen to find an issue with a software trying to call through my openser-1.3.1
After inserting "a=nortpproxy:yes\r\n", the message coming out openser is:
[normal sdp packet] a=fmtp:101 0-15\r\n \r\n \r\n "a=nortpproxy:yes\r\n"
No matter who is responsible in that specific case (the SDP received by openser with several \r\n looks not compliant to me).
I think openser should add "a=nortpproxy:yes" in different place in the SDP packet: NOT at the end of the SDP body. The "a=nortpproxy:yes" should be either put at the global attribute level or right below a m= line.
This approach would solve such issue and would be much more adequate to the requirement: currently it's not very possible to relay an audio stream and not relay a video stream with the current approach.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : jmartin@longphone.fr Web : www.longphone.com
Hi Jerome,
On 09/15/08 13:43, Jerome Martin wrote:
Hi All,
Just FYI, I had to disable the nortpproxy test here because it breaks thomson ST2030 endpoints : with that line, they would just plain ignore the messages containing the SDP ...
was i with malformed SDP (empty lines inside SDP before the a= line), or just the presence of the a=nortpproxy:yes line made the ST2030 go mad?
Cheers, Daniel
Cheers,
On Fri, 2008-09-12 at 18:12 +0300, Daniel-Constantin Mierla wrote:
On 09/11/08 16:10, Klaus Darilion wrote:
A similar bug was also described in opensips. They tried to fix it but the bug is still present. I wonder if this is something new or if the bug is thre since the beginning of nathelper but did not occured until now
maybe this can be fixed by using the sdp parser available now in core. nathelper has quite limited sdp parsing capabilities now. the issue is to find the proper hook to add the lump with
a=nortpproxy:yes\r\n"
Cheers, Daniel
klaus
Aymeric Moizard schrieb:
Hi,
I just happen to find an issue with a software trying to call through my openser-1.3.1
After inserting "a=nortpproxy:yes\r\n", the message coming out openser is:
[normal sdp packet] a=fmtp:101 0-15\r\n \r\n \r\n "a=nortpproxy:yes\r\n"
No matter who is responsible in that specific case (the SDP received by openser with several \r\n looks not compliant to me).
I think openser should add "a=nortpproxy:yes" in different place in the SDP packet: NOT at the end of the SDP body. The "a=nortpproxy:yes" should be either put at the global attribute level or right below a m= line.
This approach would solve such issue and would be much more adequate to the requirement: currently it's not very possible to relay an audio stream and not relay a video stream with the current approach.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
*Jérôme Martin **| **LongPhone* *Responsable Architecture Réseau* 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : *jmartin*@longphone.fr Web : www.longphone.com http://www.longphone.com
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
No, this is not possible!
The cancel wont have any record_route parameters.
You either have to use stateful forwarding (t_relay) or implement your own stateful solution (e.g. writing into a DB)
klaus
BERGANZ François schrieb:
Hello,
I don’t really understand, but :
I just need to do in the INVITE :
record_route_preset('$dd:$dp;codec=alaw');
forward();
and for the CANCEL:
if(check_route_param(";codec=alaw")){
route(2);}
Is it possible?
Thank you
Cordialement
BERGANZ François
http://www.acropolistelecom.net
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-
Aymeric Moizard -
BERGANZ François -
Daniel-Constantin Mierla -
Jerome Martin -
Klaus Darilion