3 May
2007
3 May
'07
2:10 p.m.
Here is the message dump that i get when using TCP as transport.
On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
I think you would have to send message dumps
first so that [serusers] volunteers
have material for providing an answer.
-jiri
At 12:07 03/05/2007, KUMAR wrote:
-
Hi all,
I already posted this message yet havent got any replies. I really
need to find this out.
Please anyone reply to this problem.
I am using SER-0.9.6 and the problem i'm having is this. When using
the following ser.cfg, it works well when the transport UDP is used.
But when transport TCP is used, then it only results in one way IM,
only from the UA from which the INVITE is being sent. Moreover, when
record_route is used instead of record_route_preset, then even that
one way IM doesn't work. But it works well with UDP.
Can anyone please point me as to where the problem might be??
Thank you in advance.
kumar
Content-Type: application/octet-stream; name=ser.cfg
X-Attachment-Id: f_f18sg2bl
Content-Disposition: attachment; filename="ser.cfg"
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
3 May
3 May
3:07 p.m.
New subject: [Serusers] Fwd: record_route..........TCP ??
actually I was suggesting SIP message dump (PCAP file) as opposed to log files. -jiri
At 13:10 03/05/2007, KUMAR wrote:
Here is the message dump that i get when using TCP as
transport.
--
Jiri Kuthan http://iptel.org/~jiri/
On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
Content-Type: audio/x-pn-realaudio-plugin; name="msg_dump.rar"
Content-Disposition: attachment; filename="msg_dump.rar"
X-Attachment-Id: f_f1949112
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers I think you would have to send message dumps
first so that [serusers] volunteers
have material for providing an answer.
-jiri
At 12:07 03/05/2007, KUMAR wrote:
-
Hi all,
I already posted this message yet havent got any replies. I really
need to find this out.
Please anyone reply to this problem.
I am using SER-0.9.6 and the problem i'm having is this. When using
the following ser.cfg, it works well when the transport UDP is used.
But when transport TCP is used, then it only results in one way IM,
only from the UA from which the INVITE is being sent. Moreover, when
record_route is used instead of record_route_preset, then even that
one way IM doesn't work. But it works well with UDP.
Can anyone please point me as to where the problem might be??
Thank you in advance.
kumar
Content-Type: application/octet-stream; name=ser.cfg
X-Attachment-Id: f_f18sg2bl
Content-Disposition: attachment; filename="ser.cfg"
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
4:39 p.m.
New subject: [Serusers] Fwd: record_route..........TCP ??
Jiri Kuthan wrote:
actually I was suggesting SIP message dump (PCAP file)
as opposed to log files. -jiri
or ngrep dump:
ngrep -t -W byline -d any port 5060
regards
klaus
At 13:10 03/05/2007, KUMAR wrote:
Here is the message dump that i get when using
TCP as transport.
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
> I think you would have to send message dumps first so that [serusers] volunteers
> have material for providing an answer.
>
> -jiri
>
> At 12:07 03/05/2007, KUMAR wrote:
>> -
>> Hi all,
>> I already posted this message yet havent got any replies. I really
>> need to find this out.
>> Please anyone reply to this problem.
>>
>> I am using SER-0.9.6 and the problem i'm having is this. When using
>> the following ser.cfg, it works well when the transport UDP is used.
>> But when transport TCP is used, then it only results in one way IM,
>> only from the UA from which the INVITE is being sent. Moreover, when
>> record_route is used instead of record_route_preset, then even that
>> one way IM doesn't work. But it works well with UDP.
>>
>> Can anyone please point me as to where the problem might be??
>> Thank you in advance.
>>
>> kumar
>>
>>
>> Content-Type: application/octet-stream; name=ser.cfg
>> X-Attachment-Id: f_f18sg2bl
>> Content-Disposition: attachment; filename="ser.cfg"
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
>
> --
> Jiri Kuthan http://iptel.org/~jiri/
>
>
Content-Type: audio/x-pn-realaudio-plugin; name="msg_dump.rar"
Content-Disposition: attachment; filename="msg_dump.rar"
X-Attachment-Id: f_f1949112
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4 May
4 May
7:07 a.m.
New subject: [Serusers] Fwd: record_route..........TCP ??
Here are the packet captures. I was not quite sure whether I have to
include packet captures from server or the UAs so i've included all of
them. ua_A is sending INVITE to ua_B.
thank you
regards
kumar
On 5/3/07, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Jiri Kuthan wrote:
actually I was suggesting SIP message dump (PCAP
file) as opposed to log files. -jiri
or ngrep dump:
ngrep -t -W byline -d any port 5060
regards
klaus
At 13:10 03/05/2007, KUMAR wrote:
Here is the message dump that i get when using
TCP as transport.
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
> I think you would have to send message dumps first so that [serusers] volunteers
> have material for providing an answer.
>
> -jiri
>
> At 12:07 03/05/2007, KUMAR wrote:
>> -
>> Hi all,
>> I already posted this message yet havent got any replies. I really
>> need to find this out.
>> Please anyone reply to this problem.
>>
>> I am using SER-0.9.6 and the problem i'm having is this. When using
>> the following ser.cfg, it works well when the transport UDP is used.
>> But when transport TCP is used, then it only results in one way IM,
>> only from the UA from which the INVITE is being sent. Moreover, when
>> record_route is used instead of record_route_preset, then even that
>> one way IM doesn't work. But it works well with UDP.
>>
>> Can anyone please point me as to where the problem might be??
>> Thank you in advance.
>>
>> kumar
>>
>>
>> Content-Type: application/octet-stream; name=ser.cfg
>> X-Attachment-Id: f_f18sg2bl
>> Content-Disposition: attachment; filename="ser.cfg"
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
>
> --
> Jiri Kuthan http://iptel.org/~jiri/
>
>
Content-Type: audio/x-pn-realaudio-plugin; name="msg_dump.rar"
Content-Disposition: attachment; filename="msg_dump.rar"
X-Attachment-Id: f_f1949112
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 
1:11 p.m.
New subject: [Serusers] sequential forking and merged request
Hello,
I have a question about sequential forking and Merged Request.
If in a forking SER calls two lines of the same client (different numbers and different
Request-URIs) it refuses the second call with 482 (Cisco and Snom multiline phone for
example) according with RFC 3261 section 8.2.2.2 because the two INVITEs have the same
Call-Id, From tag and Cseq.
If this behaviour is reasonable with a phone, it could not be acceptable for other types
of client, first of all SIP-PSTN gateway.
Is it correct this RFC interpretation? Maybe is this section inappropriate for gateways?
Is there something that I can do in the config file?
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
7 May
7 May
4:48 p.m.
New subject: [Serusers] sequential forking and merged request
Any device implementing UA functionality should follow RFC3261. But I'm
not sure how you manage to fork off two INVITEs to the same gateway? I
would start there.
g-)
Zappasodi Daniele wrote:
Hello,
I have a question about sequential forking and Merged Request.
If in a forking SER calls two lines of the same client (different numbers and different
Request-URIs) it refuses the second call with 482 (Cisco and Snom multiline phone for
example) according with RFC 3261 section 8.2.2.2 because the two INVITEs have the same
Call-Id, From tag and Cseq.
If this behaviour is reasonable with a phone, it could not be acceptable for other types
of client, first of all SIP-PSTN gateway.
Is it correct this RFC interpretation? Maybe is this section inappropriate for gateways?
Is there something that I can do in the config file?
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:36 p.m.
New subject: R: [Serusers] sequential forking and merged request
I have written a module that choose the next client reading the destination from a db, but
I can easily obtain the same scenario with the basic serial forking example:
route{
[...]
t_on_failure("1");
t_relay();
}
failure_route[1] {
append_branch("sip:number1@mygw.com");
log(1,"first redirection\n");
t_on_failure("2");
t_relay();
}
failure_route[2] {
append_branch("sip:number2@mygw.com");
log(1, "second redirection to the same gateway, but different
number\n");
t_relay();
}
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: lun 07/05/2007 15.48
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: [Serusers] sequential forking and merged request
Any device implementing UA functionality should follow RFC3261. But I'm
not sure how you manage to fork off two INVITEs to the same gateway? I
would start there.
g-)
Zappasodi Daniele wrote:
Hello,
I have a question about sequential forking and Merged Request.
If in a forking SER calls two lines of the same client (different numbers and different
Request-URIs) it refuses the second call with 482 (Cisco and Snom multiline phone for
example) according with RFC 3261 section 8.2.2.2 because the two INVITEs have the same
Call-Id, From tag and Cseq.
If this behaviour is reasonable with a phone, it could not be acceptable for other types
of client, first of all SIP-PSTN gateway.
Is it correct this RFC interpretation? Maybe is this section inappropriate for gateways?
Is there something that I can do in the config file?
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
10:07 p.m.
New subject: R: [Serusers] sequential forking and merged request
Well, in this case you need to test for the status code in the failure
route. If you fork off several INVITEs in your main route, you don't get
into the failure route until all branches failed. So, I still don't
understand how you do it.
Anyway, you want to avoid it, because you have a gateway that does not
follow the RFC...
g-)
Zappasodi Daniele wrote:
I have written a module that choose the next client reading the
destination from a db, but I can easily obtain the same scenario with
the basic serial forking example:
route{
[...]
t_on_failure("1");
t_relay();
}
failure_route[1] {
append_branch("sip:number1@mygw.com");
log(1,"first redirection\n");
t_on_failure("2");
t_relay();
}
failure_route[2] {
append_branch("sip:number2@mygw.com");
log(1, "second redirection to the same gateway, but different
number\n");
t_relay();
}
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: lun 07/05/2007 15.48
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: [Serusers] sequential forking and merged request
Any device implementing UA functionality should follow RFC3261. But I'm
not sure how you manage to fork off two INVITEs to the same gateway? I
would start there.
g-)
Zappasodi Daniele wrote:
Hello,
I have a question about sequential forking and Merged Request.
If in a forking SER calls two lines of the same client (different
numbers and
different Request-URIs) it refuses the second call with
482 (Cisco and Snom multiline phone for example) according with RFC
3261 section 8.2.2.2 because the two INVITEs have the same Call-Id,
From tag and Cseq.
If this behaviour is reasonable with a phone, it
could not be
acceptable for other types of client, first of all SIP-PSTN gateway.
Is it correct this RFC interpretation? Maybe is
this section
inappropriate for gateways?
Is there something that I can do in the config
file?
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message
by anyone else is unauthorized. If you are not
the intended
recipient, any
disclosure, copying, or distribution of the
message, or any action or
omission taken by you in reliance on it, is prohibited and may be
unlawful.
Please immediately contact the sender if you have
received this
message inerror.
**********************************************************************
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
5:55 p.m.
New subject: [Serusers] t_newtran and flags
When I invoke setflag or resetflag after t_newtran, the flags values don't change.
I use the 0.9.6 version. Is this normal?
Is there changes about this item in SER 2.0?
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
10:32 p.m.
New subject: [Serusers] t_newtran and flags
Zappasodi Daniele wrote:
When I invoke setflag or resetflag after t_newtran, the flags values
don't change.
I use the 0.9.6 version. Is this normal?
Yes, the transaction is stored in shared memory to make sure it is
accessible to other processes.
Is there changes about this item in SER 2.0?
No, I don't think so.
g-)
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4 May
4 May
1:14 p.m.
New subject: [Serusers] Fwd: record_route..........TCP ??
Hi Kumar,
could you please attach also the capture (at the server is enough) of
the UDP both way messages? There call flow is quite strange and not
understandable.... (well not surprised that's M$ RTC :)
Some comments for now:
1) it seems the CLIENT IS BROKEN and does not understand lr=on flag for
loose routing - see how is the ACK generated !!! You can try change rr
module parameter to put just lr into the record-route (this might
explain your rr and rr_preset difference)
2) M$ is used to misuse maddr, there is compile time flag HONOR_MADDR
which you should have set to route such requests taking maddr into
account
Michal
On Pá, 2007-05-04 at 09:52 +0545, KUMAR wrote:
Here are the packet captures. I was not quite sure
whether I have to
include packet captures from server or the UAs so i've included all of
them. ua_A is sending INVITE to ua_B.
thank you
regards
kumar
On 5/3/07, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Jiri Kuthan wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers actually I was suggesting SIP message dump (PCAP
file) as opposed to log files. -jiri
or ngrep dump:
ngrep -t -W byline -d any port 5060
regards
klaus
At 13:10 03/05/2007, KUMAR wrote:
Here is the message dump that i get when using
TCP as transport.
>
> On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
>> I think you would have to send message dumps first so that [serusers] volunteers
>> have material for providing an answer.
>>
>> -jiri
>>
>> At 12:07 03/05/2007, KUMAR wrote:
>>> -
>>> Hi all,
>>> I already posted this message yet havent got any replies. I really
>>> need to find this out.
>>> Please anyone reply to this problem.
>>>
>>> I am using SER-0.9.6 and the problem i'm having is this. When using
>>> the following ser.cfg, it works well when the transport UDP is used.
>>> But when transport TCP is used, then it only results in one way IM,
>>> only from the UA from which the INVITE is being sent. Moreover, when
>>> record_route is used instead of record_route_preset, then even that
>>> one way IM doesn't work. But it works well with UDP.
>>>
>>> Can anyone please point me as to where the problem might be??
>>> Thank you in advance.
>>>
>>> kumar
>>>
>>>
>>> Content-Type: application/octet-stream; name=ser.cfg
>>> X-Attachment-Id: f_f18sg2bl
>>> Content-Disposition: attachment; filename="ser.cfg"
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>> --
>> Jiri Kuthan http://iptel.org/~jiri/
>>
>>
Content-Type: audio/x-pn-realaudio-plugin; name="msg_dump.rar"
Content-Disposition: attachment; filename="msg_dump.rar"
X-Attachment-Id: f_f1949112
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7 May
7 May
7:19 a.m.
New subject: [Serusers] Fwd: record_route..........TCP ??
Hi Michal,
Sorry for my late response. Here are the packets while the transport
UDP is used.
regards
kumar
On 5/4/07, Michal Matyska <michal(a)iptel.org> wrote:
Hi Kumar,
could you please attach also the capture (at the server is enough) of
the UDP both way messages? There call flow is quite strange and not
understandable.... (well not surprised that's M$ RTC :)
Some comments for now:
1) it seems the CLIENT IS BROKEN and does not understand lr=on flag for
loose routing - see how is the ACK generated !!! You can try change rr
module parameter to put just lr into the record-route (this might
explain your rr and rr_preset difference)
2) M$ is used to misuse maddr, there is compile time flag HONOR_MADDR
which you should have set to route such requests taking maddr into
account
Michal
On Pá, 2007-05-04 at 09:52 +0545, KUMAR wrote:
Here are the packet captures. I was not quite
sure whether I have to
include packet captures from server or the UAs so i've included all of
them. ua_A is sending INVITE to ua_B.
thank you
regards
kumar
On 5/3/07, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Jiri Kuthan wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers actually I was suggesting SIP message dump (PCAP
file) as opposed to log files. -jiri
or ngrep dump:
ngrep -t -W byline -d any port 5060
regards
klaus
At 13:10 03/05/2007, KUMAR wrote:
> Here is the message dump that i get when using TCP as transport.
>>
>> On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
>>> I think you would have to send message dumps first so that [serusers]
volunteers
>>> have material for providing an answer.
>>>
>>> -jiri
>>>
>>> At 12:07 03/05/2007, KUMAR wrote:
>>>> -
>>>> Hi all,
>>>> I already posted this message yet havent got any replies. I really
>>>> need to find this out.
>>>> Please anyone reply to this problem.
>>>>
>>>> I am using SER-0.9.6 and the problem i'm having is this. When using
>>>> the following ser.cfg, it works well when the transport UDP is used.
>>>> But when transport TCP is used, then it only results in one way IM,
>>>> only from the UA from which the INVITE is being sent. Moreover, when
>>>> record_route is used instead of record_route_preset, then even that
>>>> one way IM doesn't work. But it works well with UDP.
>>>>
>>>> Can anyone please point me as to where the problem might be??
>>>> Thank you in advance.
>>>>
>>>> kumar
>>>>
>>>>
>>>> Content-Type: application/octet-stream; name=ser.cfg
>>>> X-Attachment-Id: f_f18sg2bl
>>>> Content-Disposition: attachment; filename="ser.cfg"
>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> Serusers(a)lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>> --
>>> Jiri Kuthan http://iptel.org/~jiri/
>>>
>>>
>
> Content-Type: audio/x-pn-realaudio-plugin; name="msg_dump.rar"
> Content-Disposition: attachment; filename="msg_dump.rar"
> X-Attachment-Id: f_f1949112
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
3:59 p.m.
New subject: [Serusers] Fwd: record_route..........TCP ??
Hi,
commetns inline
On Po, 2007-05-07 at 10:04 +0545, KUMAR wrote:
Hi Michal,
Sorry for my late response. Here are the packets while the transport
UDP is used.
regards
kumar
On 5/4/07, Michal Matyska <michal(a)iptel.org> wrote:
> Hi Kumar,
>
> could you please attach also the capture (at the server is enough) of
> the UDP both way messages? There call flow is quite strange and not
> understandable.... (well not surprised that's M$ RTC :)
>
> Some comments for now:
> 1) it seems the CLIENT IS BROKEN and does not understand lr=on flag for
> loose routing - see how is the ACK generated !!! You can try change rr
> module parameter to put just lr into the record-route (this might
> explain your rr and rr_preset difference)
Taking back, the client code is not broken, it is obsoleted only ;-)
It uses strict router procedures (RFC2543), to create the Route header
and Request-URI in subsequent within-dialog requests, but SER's
loose_route function call should be able to escape form that (and it is,
the rewritten request uri shows that). If you want to check, you should
see "after_strict" message in your debug output.
> 2) M$ is used to misuse maddr, there is compile
time flag HONOR_MADDR
> which you should have set to route such requests taking maddr into
> account
This seems to be the main issue, the client does not put maddr into the
UDP requests. Check the Route header from the client in the TCP and UDP
captures to see the difference.
Recompile SER with the option HONOR_MADDR set and it should work. If
not, please provide SER output with debug=4 statement in you ser.cfg,
while running the TCP usecase.
Michal
> On Pá, 2007-05-04 at 09:52 +0545, KUMAR wrote:
> > Here are the packet captures. I was not quite sure whether I have to
> > include packet captures from server or the UAs so i've included all of
> > them. ua_A is sending INVITE to ua_B.
> > thank you
> >
> > regards
> > kumar
> >
> > On 5/3/07, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
> > >
> > >
> > > Jiri Kuthan wrote:
> > > > actually I was suggesting SIP message dump (PCAP file) as opposed to
log files. -jiri
> > >
> > > or ngrep dump:
> > >
> > > ngrep -t -W byline -d any port 5060
> > >
> > > regards
> > > klaus
> > >
> > >
> > > >
> > > > At 13:10 03/05/2007, KUMAR wrote:
> > > >> Here is the message dump that i get when using TCP as transport.
> > > >>>
> > > >>> On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
> > > >>>> I think you would have to send message dumps first so
that [serusers] volunteers
> > > >>>> have material for providing an answer.
> > > >>>>
> > > >>>> -jiri
> > > >>>>
> > > >>>> At 12:07 03/05/2007, KUMAR wrote:
> > > >>>>> -
> > > >>>>> Hi all,
> > > >>>>> I already posted this message yet havent got any
replies. I really
> > > >>>>> need to find this out.
> > > >>>>> Please anyone reply to this problem.
> > > >>>>>
> > > >>>>> I am using SER-0.9.6 and the problem i'm having
is this. When using
> > > >>>>> the following ser.cfg, it works well when the
transport UDP is used.
> > > >>>>> But when transport TCP is used, then it only results
in one way IM,
> > > >>>>> only from the UA from which the INVITE is being sent.
Moreover, when
> > > >>>>> record_route is used instead of record_route_preset,
then even that
> > > >>>>> one way IM doesn't work. But it works well with
UDP.
> > > >>>>>
> > > >>>>> Can anyone please point me as to where the problem
might be??
> > > >>>>> Thank you in advance.
> > > >>>>>
> > > >>>>> kumar
> > > >>>>>
> > > >>>>>
> > > >>>>> Content-Type: application/octet-stream; name=ser.cfg
> > > >>>>> X-Attachment-Id: f_f18sg2bl
> > > >>>>> Content-Disposition: attachment;
filename="ser.cfg"
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> Serusers mailing list
> > > >>>>> Serusers(a)lists.iptel.org
> > > >>>>> http://lists.iptel.org/mailman/listinfo/serusers
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Jiri Kuthan http://iptel.org/~jiri/
> > > >>>>
> > > >>>>
> > > >>
> > > >> Content-Type: audio/x-pn-realaudio-plugin;
name="msg_dump.rar"
> > > >> Content-Disposition: attachment;
filename="msg_dump.rar"
> > > >> X-Attachment-Id: f_f1949112
> > > >>
> > > >> _______________________________________________
> > > >> Serusers mailing list
> > > >> Serusers(a)lists.iptel.org
> > > >> http://lists.iptel.org/mailman/listinfo/serusers
> > > >
> > > >
> > > >
> > > > --
> > > > Jiri Kuthan http://iptel.org/~jiri/
> > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > Serusers(a)lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > >
> > _______________________________________________
> > Serusers mailing list
> > Serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
>
>
6413
days inactive
6417
days old
12 comments
6 participants
participants (6)
-
Greger V. Teigre -
Jiri Kuthan -
Klaus Darilion -
KUMAR -
Michal Matyska -
Zappasodi Daniele