7 Feb
2012
7 Feb
'12
11:13 a.m.
Hi,
anyone knows why the dialog module leaves active dialogs even after a bye
was recieved when using sipp?
once i had issues with the record route and i forced sipp to deal with
that, is there something to set on the bye sent by sipp?
BR,
Uri
7 Feb
7 Feb
2 p.m.
Am 07.02.2012 um 17:13 schrieb Uri Shacked:
anyone knows why the dialog module leaves active
dialogs even after a bye was recieved when using sipp?
once i had issues with the record route and i forced sipp to deal with that, is there
something to set on the bye sent by sipp?
From my experience, it's quite tricky to please the dialog module using sipp. Not
because of the dialog module but because of sipp which needs some fine-tuning from a
dialog perspective.
My BYE message emitted from sipp looks something like this:
<send>
<![CDATA[
BYE [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
[routes]
From: <sip:[service]@[local_ip]>;tag=[call_number]
To: <sip:[field0]@[remote_ip]>[peer_tag_param]
Call-ID: [call_id]
CSeq: [cseq] BYE
Contact: sip:[service]@127.0.0.1:[local_port]
Max-Forwards: 70
Subject: Conversation over
Content-Length: 0
]]>
</send>
If that's not helpful enough, my suggestion is to take a working (i.e.,
dialog-conforming) real-world call and try to match your sipp scenario gradually. That is,
you should verify for each message in the sipp call flow whether it produces the very same
dialog state generated by the mirroring real-world call flow. If it fails to do so with
some message, compare the sipp/real message line by line and try to match further.
HTH,
--Timo
8 Feb
8 Feb
6:38 a.m.
thanks
On Tue, Feb 7, 2012 at 9:00 PM, Timo Reimann <sr(a)foo-lounge.de> wrote:
Am 07.02.2012 um 17:13 schrieb Uri Shacked:
anyone knows why the dialog module leaves active
dialogs even after a
bye was recieved when using sipp?
once i had issues with the record route and i
forced sipp to deal with
that, is there something to set on the bye sent by sipp?
From my experience, it's quite tricky to please the dialog module using
sipp. Not because of the dialog module but because of sipp which needs some
fine-tuning from a dialog perspective.
My BYE message emitted from sipp looks something like this:
<send>
<![CDATA[
BYE [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
[routes]
From: <sip:[service]@[local_ip]>;tag=[call_number]
To: <sip:[field0]@[remote_ip]>[peer_tag_param]
Call-ID: [call_id]
CSeq: [cseq] BYE
Contact: sip:[service]@127.0.0.1:[local_port]
Max-Forwards: 70
Subject: Conversation over
Content-Length: 0
]]>
</send>
If that's not helpful enough, my suggestion is to take a working (i.e.,
dialog-conforming) real-world call and try to match your sipp scenario
gradually. That is, you should verify for each message in the sipp call
flow whether it produces the very same dialog state generated by the
mirroring real-world call flow. If it fails to do so with some message,
compare the sipp/real message line by line and try to match further.
HTH,
--Timo
4706
days inactive
4707
days old
2 comments
2 participants
participants (2)
-
Timo Reimann -
Uri Shacked