I copied a few SNOM phone messages to the list.
I am having problems communicating with the
SNOM phone.
I guess it isn't working because the SNOM phone
sends a PRACK after the 183, and the received
OK doesn't have a 'Record-Route'. This doesn't make
sense to me. I don't know why the phone is listening
to the first OK (the OK to the PRACK) rather than the
second OK (the OK to the INVITE).
If that is the way it is then do I have the PROXY mis-configured?
-----
if(method=="INVITE" | method=="BYE" | method=="PRACK")
{
log(1,"TRACE: addRecordRoute()");
setflag(1);
setflag(2);
addRecordRoute();
};
append_hf("P-hint: ATEND\r\n");
if(!t_relay())
{
sl_reply_error();
break;
};
When I do a ngrep trace, I see the packet being relayed...
----
#
U 2003/03/03 20:05:59.858473 216.87.145.22:5060 -> 216.87.144.203:5060
PRACK sip:2143357976@216.87.144.203;branch=0 SIP/2.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 70.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Route: <sip:92143357976@216.87.144.196:5060;user=phone>.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b3300000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b828395cd40fe1b1
ab5f9ad61308",algorithm=md5.
.
#
U 2003/03/03 20:05:59.859540 216.87.144.203:5060 -> 216.87.144.196:5060
PRACK sip:92143357976@216.87.144.196:5060;user=phone SIP/2.0.
Record-Route: <sip:2143357976@216.87.144.203;branch=0>.
Via: SIP/2.0/UDP 216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 69.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b3300000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b828395cd40fe1b1
ab5f9ad61308",algorithm=md5.
P-hint: ATEND.
.
#
U 2003/03/03 20:05:59.861477 216.87.144.196:5060 -> 216.87.144.203:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0,SIP/2.0/UDP
216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
#
U 2003/03/03 20:05:59.861705 216.87.144.203:5060 -> 216.87.145.22:5060
SIP/2.0 200 OK.
Via:SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
-----
There is a Record-route going out, but not one coming back.
Does a Record-route need to be injected into the last
OK back to the UA?
This is too hard :-)
---greg
I installed ser stable then unstable debs on my 2.2.20 kernel install of
unstable debian.
Errors:
when init.d/ser start:
Starting ser: serToo much shared memory demanded: 33554432
Terminated
SYSLOG:
Mar 5 10:09:19 webserver ser: ERROR: shm_mem_init: could not attach
shared
memo
ry segment: Invalid argument
Mar 5 10:09:19 webserver ser: could not initialize shared memory pool,
exiting.
a friend sent me:
scmctl
from shmctl(2):
Various fields in a struct shmid_ds were shorts under Linux 2.2 and
have become longs under Linux 2.4. To take advantage of this, a
recompilation under glibc-2.1.91 or later should suffice. (The kernel dis-tinguishes
old and new calls by a IPC_64 flag in cmd.)
Do I need kernel 2.4? Any hints? Have I missed some documentation?
Jaime Hemmett
At 03:08 PM 3/4/2003, Ng, Soo Sim wrote:
>I have such requirements. In providing sip-based residential ip telephony, I would like to restrict each home subsriber is only allowed to register one UA per account. This would make easy for billing purposes and for security reasons.
>
>Is there a way to achieve this requirement with SER?
If that is your desparate wish, it is little overhead to make you happy.
I'm still not sure though, it is a useful thing.
Maybe an operator can make more revennues if my wife can accept calls at
any phone in my building and initiate calls in parallel with my doughter.
What are exactly the billing/security reasons here?
-Jiri
Jan Janak writes: > Yes, several UAs can register with the same account and currently there > is no way in ser how to prevent it. Do you really need such a > restriction ? If you do that, users will be unable to register several > phones or user agents and utilize forking, for example. yes, i agree that allowing many uas to register the same uri is very useful. the only problem that i see in ser regarding it is that ser doesn't yet implement sequential forking based on the q value. it would we great if first my sip ua would ring and it that times out, then my mobile phone would ring. -- juha
============
I have such requirements. In providing sip-based residential ip telephony, I would like to restrict each home subsriber is only allowed to register one UA per account. This would make easy for billing purposes and for security reasons.
Is there a way to achieve this requirement with SER?
Hi,
I'm writing a module which requires to see request messages and also
responses. So I have declared a response_function. The function looks like:
static int fi_response(struct sip_msg* msg, char* str1, char* str2);
and I put it into the module_exports structure like this:
#ifdef STATIC_FI
struct module_exports fi_exports = {
#else
struct module_exports exports= {
#endif
"fi_module",
(char*[]){ "fi_request", "fi_response" },
(cmd_function[]){ fi_request, fi_response },
(int[]){ 0, 0 },
(fixup_function[]){ 0 },
2, /* Number of exported functions*/
NULL, /* Module parameter names */
NULL, /* Module parameter types */
NULL, /* Module parameter variable pointers */
0, /* Number of module paramers */
mod_init,
fi_response,
(destroy_function) 0,
0,
0
};
I'm wondering if I correctly declared the function as I'm getting a
warning during compilation about incompatible pointer types (4th last
line in structure where the function is declared as response function).
I really only need the message as parameter. What should the parameters be?
This is for the CVS version of SER.
Thanks very much for your help!
Regards,
Mario
--
Mario Kolberg phone: +44 (0)1786 46 7440
Lecturer in Computing Science fax : +44 (0)1786 46 4551
email: mko(a)cs.stir.ac.uk
Department of Computing Science and Mathematics
University of Stirling
Stirling FK9 4LA
Scotland, UK
--
The University of Stirling is a university established in Scotland by
charter at Stirling, FK9 4LA. Privileged/Confidential Information may
be contained in this message. If you are not the addressee indicated
in this message (or responsible for delivery of the message to such
person), you may not disclose, copy or deliver this message to anyone
and any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful. In such case, you should destroy this
message and kindly notify the sender by reply email. Please advise
immediately if you or your employer do not consent to Internet email
for messages of this kind. Opinions, conclusions and other
information in this message that do not relate to the official
business of the University of Stirling shall be understood as neither
given nor endorsed by it.
Hi,
I'm using the CVS version of SER and I found a frequent error message in
the SER log. I'm not sure what this means.
Mar 4 12:06:08 DISCUS /usr/local/sbin/ser[1020]: ERROR: set_kr:
kill_reason reset: from=1 to=2
Mar 4 12:06:08 DISCUS /usr/local/sbin/ser[1020]: ERROR: set_kr:
kill_reason reset: from=1 to=2
The error usually occurs in pairs, but the values for 'from' and 'to'
vary. How can I fix it?
Thanks!
Mario
--
Mario Kolberg phone: +44 (0)1786 46 7440
Lecturer in Computing Science fax : +44 (0)1786 46 4551
email: mko(a)cs.stir.ac.uk
Department of Computing Science and Mathematics
University of Stirling
Stirling FK9 4LA
Scotland, UK
--
The University of Stirling is a university established in Scotland by
charter at Stirling, FK9 4LA. Privileged/Confidential Information may
be contained in this message. If you are not the addressee indicated
in this message (or responsible for delivery of the message to such
person), you may not disclose, copy or deliver this message to anyone
and any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful. In such case, you should destroy this
message and kindly notify the sender by reply email. Please advise
immediately if you or your employer do not consent to Internet email
for messages of this kind. Opinions, conclusions and other
information in this message that do not relate to the official
business of the University of Stirling shall be understood as neither
given nor endorsed by it.
Greg,
ooppss that actually changes the scene. Maybe it was too late for me
last night already You are right, the 200 Ok goes to the PRACK and the
phone mixes that up. I changed it in the phone code and that will be
part of the next release.
Thanks,
Christian
-----Ursprüngliche Nachricht-----
Von: Robert Messer [mailto:rmesser@abpintl.com]
Gesendet: Dienstag, 4. März 2003 02:25
An: cs(a)snom.de
Betreff: FW: Snom phone (fwd) more fromn greg fausak
FYI More from greg
Robert Messer
972-745-1220 Direct
___________________
ABP International, Inc.
snom technology - VoIP Phones
www.abptech.com
972-745-1221 Phone
972-745-1226 Fax
-----Original Message-----
From: Greg Fausak [mailto:greg@august.net]
Sent: Monday, March 03, 2003 6:13 PM
To: 'Kevin'
Cc: 'Robert Messer'; sip(a)august.net; serusers(a)lists.iptel.org
Subject: RE: Snom phone (fwd)
Kevin,
I initially sent the packet:
> > > This is that packet that came from the last 200 OK <- PROXY:
> > >
> > > #
> > > U 2003/02/24 07:56:52.503535 216.87.144.203:5060 ->
> > 216.87.145.22:5060
> > > SIP/2.0 200 OK.
> > > Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r.
> > > From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc.
> > > To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532.
> > > Date: Mon, 24 Feb 2003 13:56:43 GMT.
> > > Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22.
> > > Server: Cisco-SIPGateway/IOS-12.x.
> > > CSeq: 2 INVITE.
> > > Session-Expires: 7200;refresher=uac.
> > > Require: timer.
> > > Allow-Events: telephone-event.
> > > Contact: <sip:92143357976@216.87.144.196:5060;user=phone>.
> > > Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>.
> > > Content-Type: application/sdp.
> > > Content-Length: 209.
> > > .
> > > v=0.
> > > o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196.
> > > s=SIP Call.
> > > c=IN IP4 216.87.144.196.
> > > t=0 0.
> > > m=audio 16632 RTP/AVP 0 100.
> > > a=rtpmap:0 PCMU/8000.
> > > a=rtpmap:100 X-NSE/8000.
> > > a=fmtp:100 192-194.
> > >
This is the 200 OK (response to the INVITE) message as delivered to the
phone.
I couldn't figure out what you were saying, so I went back to
the ethereal trace. After the snom phone receives a 183 status
message, it sends a PRACK to the PROXY. This PRACK is
OKed, without a Record-route. The next message is an OK
responding to the original INVITE, which does indeed have a
Record-Route.
So, you are saying that the OK to your PRACK needs a record route?
I can do that I think, because the OK to the INVITE does indeed have
a Record-route.
I don't even know what a PRACK is for...
---greg
-----Original Message-----
From: Kevin [mailto:kmoroz@abpintl.com]
Sent: Monday, March 03, 2003 5:19 PM
To: Greg Fausak
Cc: 'Robert Messer'
Subject: FW: Snom phone (fwd)
Hi Greg,
Sorry it took so long to get back to you. Normally it is faster but
as I stated the SIP inter-
operability was last week which caused the delay. Looks like the issue
is with the
SER proxy. If I knew the specification deeper I should have been able
to answer it myself. Engineering ccs Jiri on their response to me so
he is aware of the issue.
Regards,
Kevin
-----Original Message-----
The phone updates the route until it receives a 2xx code. The 200 Ok
response does not contain such a route therefore the phone uses the last
route it receives in the 200 which is empty. Therefore, the phone MUST
send the ACK directly to the gateway.
§ 12.1.2 of the RFC3261. The dialog is NOT established by the
401-challened request.
The proxy can very easily solve the problem by putting itself into the
routing path of the 200 Ok.
Robert,
the gateway mandates PRACK, that cant be turned off. The OPTIONS can be
avoided if the phone is set to use REFER explicitly.
CS
-----Ursprüngliche Nachricht-----
Von: Robert Messer [mailto:rmesser@abpintl.com]
Gesendet: Dienstag, 4. März 2003 05:58
An: cs(a)snom.de
Betreff: RE: Snom phone (fwd)
Kevin,
I will try to modify the code accordingly, however,
I've been looking at the OPTIONS tag. Perhaps I can tell the
snom phone not to use PRACK? I'll look into that.
Thanks,
---greg
-----Original Message-----
From: Kevin [mailto:kmoroz@abpintl.com]
Sent: Monday, March 03, 2003 8:09 PM
To: 'Greg Fausak'
Cc: 'Robert Messer'; sip(a)august.net; serusers(a)lists.iptel.org
Subject: RE: Snom phone (fwd)
Greg,
According to snom engineering you should put the routing
information in the first 200 OK we receive. Can you do that and try it?
You can test against my proxy if you like to see how it should work.
Regards,
Kevin
-----Original Message-----
From: Greg Fausak [mailto:greg@august.net]
Sent: Monday, March 03, 2003 7:13 PM
To: 'Kevin'
Cc: 'Robert Messer'; sip(a)august.net; serusers(a)lists.iptel.org
Subject: RE: Snom phone (fwd)
Kevin,
I initially sent the packet:
> > > This is that packet that came from the last 200 OK <- PROXY:
> > >
> > > #
> > > U 2003/02/24 07:56:52.503535 216.87.144.203:5060 ->
> > 216.87.145.22:5060
> > > SIP/2.0 200 OK.
> > > Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r.
> > > From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc.
> > > To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532.
> > > Date: Mon, 24 Feb 2003 13:56:43 GMT.
> > > Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22.
> > > Server: Cisco-SIPGateway/IOS-12.x.
> > > CSeq: 2 INVITE.
> > > Session-Expires: 7200;refresher=uac.
> > > Require: timer.
> > > Allow-Events: telephone-event.
> > > Contact: <sip:92143357976@216.87.144.196:5060;user=phone>.
> > > Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>.
> > > Content-Type: application/sdp.
> > > Content-Length: 209.
> > > .
> > > v=0.
> > > o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196.
> > > s=SIP Call.
> > > c=IN IP4 216.87.144.196.
> > > t=0 0.
> > > m=audio 16632 RTP/AVP 0 100.
> > > a=rtpmap:0 PCMU/8000.
> > > a=rtpmap:100 X-NSE/8000.
> > > a=fmtp:100 192-194.
> > >
This is the 200 OK (response to the INVITE) message as delivered to the
phone.
I couldn't figure out what you were saying, so I went back to
the ethereal trace. After the snom phone receives a 183 status
message, it sends a PRACK to the PROXY. This PRACK is
OKed, without a Record-route. The next message is an OK
responding to the original INVITE, which does indeed have a
Record-Route.
So, you are saying that the OK to your PRACK needs a record route?
I can do that I think, because the OK to the INVITE does indeed have
a Record-route.
I don't even know what a PRACK is for...
---greg
-----Original Message-----
From: Kevin [mailto:kmoroz@abpintl.com]
Sent: Monday, March 03, 2003 5:19 PM
To: Greg Fausak
Cc: 'Robert Messer'
Subject: FW: Snom phone (fwd)
Hi Greg,
Sorry it took so long to get back to you. Normally it is faster but
as I stated the SIP inter-
operability was last week which caused the delay. Looks like the issue
is with the
SER proxy. If I knew the specification deeper I should have been able
to answer it myself. Engineering ccs Jiri on their response to me so
he is aware of the issue.
Regards,
Kevin
-----Original Message-----
The phone updates the route until it receives a 2xx code. The 200 Ok
response does not contain such a route therefore the phone uses the last
route it receives in the 200 which is empty. Therefore, the phone MUST
send the ACK directly to the gateway.
§ 12.1.2 of the RFC3261. The dialog is NOT established by the
401-challened request.
The proxy can very easily solve the problem by putting itself into the
routing path of the 200 Ok.
Kevin,
I initially sent the packet:
> > > This is that packet that came from the last 200 OK <- PROXY:
> > >
> > > #
> > > U 2003/02/24 07:56:52.503535 216.87.144.203:5060 ->
> > 216.87.145.22:5060
> > > SIP/2.0 200 OK.
> > > Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r.
> > > From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc.
> > > To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532.
> > > Date: Mon, 24 Feb 2003 13:56:43 GMT.
> > > Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22.
> > > Server: Cisco-SIPGateway/IOS-12.x.
> > > CSeq: 2 INVITE.
> > > Session-Expires: 7200;refresher=uac.
> > > Require: timer.
> > > Allow-Events: telephone-event.
> > > Contact: <sip:92143357976@216.87.144.196:5060;user=phone>.
> > > Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>.
> > > Content-Type: application/sdp.
> > > Content-Length: 209.
> > > .
> > > v=0.
> > > o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196.
> > > s=SIP Call.
> > > c=IN IP4 216.87.144.196.
> > > t=0 0.
> > > m=audio 16632 RTP/AVP 0 100.
> > > a=rtpmap:0 PCMU/8000.
> > > a=rtpmap:100 X-NSE/8000.
> > > a=fmtp:100 192-194.
> > >
This is the 200 OK (response to the INVITE) message as delivered to the
phone.
I couldn't figure out what you were saying, so I went back to
the ethereal trace. After the snom phone receives a 183 status
message, it sends a PRACK to the PROXY. This PRACK is
OKed, without a Record-route. The next message is an OK
responding to the original INVITE, which does indeed have a
Record-Route.
So, you are saying that the OK to your PRACK needs a record route?
I can do that I think, because the OK to the INVITE does indeed have
a Record-route.
I don't even know what a PRACK is for...
---greg
-----Original Message-----
From: Kevin [mailto:kmoroz@abpintl.com]
Sent: Monday, March 03, 2003 5:19 PM
To: Greg Fausak
Cc: 'Robert Messer'
Subject: FW: Snom phone (fwd)
Hi Greg,
Sorry it took so long to get back to you. Normally it is faster but
as I stated the SIP inter-
operability was last week which caused the delay. Looks like the issue
is with the
SER proxy. If I knew the specification deeper I should have been able
to answer it myself. Engineering ccs Jiri on their response to me so
he is aware of the issue.
Regards,
Kevin
-----Original Message-----
The phone updates the route until it receives a 2xx code. The 200 Ok
response does not contain such a route therefore the phone uses the last
route it receives in the 200 which is empty. Therefore, the phone MUST
send the ACK directly to the gateway.
§ 12.1.2 of the RFC3261. The dialog is NOT established by the
401-challened request.
The proxy can very easily solve the problem by putting itself into the
routing path of the 200 Ok.
