[OpenSER-Users] Problem with "uac_replace_from()" and Linksys PAP: "vsf" parameter in Record-Route
3 Jan
2008
3 Jan
'08
12:21 p.m.
Hi, I use "uac_replace_from" with:
modparam("uac","from_restore_mode","auto")
modparam("uac","rr_store_param","vsf")
So when a call arrives and must be sent to an Asterisk voicemail server I
change the From:
Linksys PAP -> OpenSer
INVITE sip:*500@openser.ilimit.es SIP/2.0
Via: SIP/2.0/UDP 192.168.1.109:5061;branch=z9hG4bK-91c6d79a
From: PAP809 <sip:809@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>
Call-ID: 148834d2-a640054a(a)192.168.1.109
OpenSer -> Asterisk
INVITE sip:*500@80.94.0.111 SIP/2.0
Record-Route:
<sip:80.94.0.110;lr=on;ftag=bd9af3255e5ce6ao1;vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw-->
Via: SIP/2.0/UDP 80.94.0.110;branch=z9hG4bKb114.2e2e6ca5.0
Via: SIP/2.0/UDP
192.168.1.109:5061;rport=5061;received=212.121.235.18;branch=z9hG4bK-91c6d79a
From: PAP809 <sip:809_openser.ilimit.es@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>
Call-ID: 148834d2-a640054a(a)192.168.1.109
Asterisk -> OpenSer
SIP/2.0 200 OK
Via: SIP/2.0/UDP 80.94.0.110;branch=z9hG4bKb114.2e2e6ca5.0;received=80.94.0.110
Via: SIP/2.0/UDP
192.168.1.109:5061;rport=5061;received=212.121.235.18;branch=z9hG4bK-91c6d79a
Record-Route:
<sip:80.94.0.110;lr=on;ftag=bd9af3255e5ce6ao1;vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw-->
From: PAP809 <sip:809_openser.ilimit.es@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>;tag=as32a464eb
Call-ID: 148834d2-a640054a(a)192.168.1.109
OpenSer -> Linksys PAP
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.1.109:5061;rport=5061;received=212.121.235.18;branch=z9hG4bK-91c6d79a
Record-Route:
<sip:80.94.0.110;lr=on;ftag=bd9af3255e5ce6ao1;vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw-->
From: PAP809 <sip:809@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>;tag=as32a464eb
Call-ID: 148834d2-a640054a(a)192.168.1.109
The problem is that this "200 OK" from OpenSer to Linksys PAP is not recognized
by Linksys PAP
who doesn't reply with an ACK (just ignores the "200 OK"), so the "200
OK" is resent again
and again by Asterisk.
This issue just occurs with the Linksys PAP:
Product Name: PAP2-NA
Software Version: 2.0.12(LS) Hardware Version: 0.03.4
There is no NAT problem and if I set:
modparam("uac","from_restore_mode","none")
then the problem dissapeares, so the problem is the existence of "vsf" parameter
in Record-Route.
If this parameter doesn't exist the problem doesn't occur.
Again I repeat that this issue doesn't occur with others phones. Any idea of why this
occurs
with Linksys PAP? Thanks for any suggestion.
PD: Changing the parameter name does solve nothing.
PPD: What about if I don't restore the From in the replies? According to RFC3261 the
only important is the
matching of From_tag, To_tag and Call-id, so, maybe I just should set:
modparam("uac","from_restore_mode","none")
and forget this issue?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
3 Jan
3 Jan
1:36 p.m.
New subject: [OpenSER-Users] Problem with "uac_replace_from()" and Linksys PAP: "vsf" parameter in Record-Route
Hola Iñaki,
The problem is that this "200 OK" from
OpenSer to Linksys PAP is not
recognized by Linksys PAP
who doesn't reply with an ACK (just ignores the "200 OK"), so the
"200 OK" is resent again
and again by Asterisk.
This issue just occurs with the Linksys PAP:
Product Name: PAP2-NA
Software Version: 2.0.12(LS) Hardware Version: 0.03.4
I would recommend to upgrade the firmware version of the PAP2. Version
2.0.12 is a pretty old.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
1:58 p.m.
New subject: [OpenSER-Users] Problem with "uac_replace_from()" and Linksys PAP: "vsf" parameter in Record-Route
On Thursday 03 January 2008 12:36:24 Jesus Rodriguez wrote:
Hola Iñaki,
Yes, I upgraded to 3.1.22(LS) and the issue has dissapeared.
Anyway it scares me a little if some UAC don't allow certains parameters as:
vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw--
Maybe Linksys with old firmware didn't accepted that parameter because it's
very long. Other parameters as "dialog" were allowed in Record-Route header.
Obviosly it's a bug in Linksys, but hope it doesn't occur in other common
UACs.
Thank a lot ;)
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
The problem is that this "200 OK" from
OpenSer to Linksys PAP is not
recognized by Linksys PAP
who doesn't reply with an ACK (just ignores the "200 OK"), so the
"200 OK" is resent again
and again by Asterisk.
This issue just occurs with the Linksys PAP:
Product Name: PAP2-NA
Software Version: 2.0.12(LS) Hardware Version: 0.03.4
I would recommend to upgrade the firmware version of the PAP2. Version
2.0.12 is a pretty old. 
5 Jan
5 Jan
3:31 a.m.
New subject: [OpenSER-Users] Problem with "uac_replace_from()" and Linksys PAP: "vsf" parameter in Record-Route
Seems pertinent to the situation so may as well mention it....
Most modern UACs are RFC3261 compliant and shouldn't have this problem.
However, I have seen similar problems with this "vsf" parameter on other
systems, namely interconnecting a VoiceMaster platform with OpenSER
1.1.1using uac_replace_from.
In this particular scenario VoiceMaster was receiving the 200 OK reply from
OpenSER but was responding with an ACK in which the "vsf" parameters had
been modified (i.e. changed from a mixture of lower and uppercase characters
to *only* lowercase).
Somewhere in the RFC it seems to suggest that if a UAC does not understand
the "vsf" parameters it should not modify them in the response it sends back
so clearly in this case, the VoiceMaster system was at fault. Nonetheless it
resulted in some rather ackward behaviour in OpenSER, since after the
uac_replace_from function was applied to the received ACK, the "From" field
was replaced with gibberish, which once forwarded to the destination gateway
or SIP A/S, the SIP A/S was unable to process. Hence, you ended up with the
behaviour you described above, - i.e. the 200 OK is retransmitted over and
over again until the request finally timed out.
(By "gibberish" I am referring to garbage characters like you would see in a
binary file. Perhaps the result of a memory leak.)
I can only imagine that such UACs are perhaps conforming to the older RFC
2543 SIP standard, which does not use such parameters.
On 03/01/2008, Iñaki Baz Castillo <ibc(a)in.ilimit.es> wrote:
On Thursday 03 January 2008 12:36:24 Jesus Rodriguez wrote:
Hola Iñaki,
Yes, I upgraded to 3.1.22(LS) and the issue has dissapeared.
Anyway it scares me a little if some UAC don't allow certains parameters
as:
vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw--
Maybe Linksys with old firmware didn't accepted that parameter because
it's
very long. Other parameters as "dialog" were allowed in Record-Route
header.
Obviosly it's a bug in Linksys, but hope it doesn't occur in other common
UACs.
Thank a lot ;)
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
The problem is that this "200 OK" from
OpenSer to Linksys PAP is not
recognized by Linksys PAP
who doesn't reply with an ACK (just ignores the "200 OK"), so the
"200 OK" is resent again
and again by Asterisk.
This issue just occurs with the Linksys PAP:
Product Name: PAP2-NA
Software Version: 2.0.12(LS) Hardware Version: 0.03.4
I would recommend to upgrade the firmware version of the PAP2. Version
2.0.12 is a pretty old.
6196
days inactive
6198
days old
3 comments
3 participants
participants (3)
-
Iñaki Baz Castillo -
Jesus Rodriguez -
Max Gregorian