---
src/sdpd-service.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/sdpd-service.c b/src/sdpd-service.c
index cf120b8..df9017e 100644
--- a/src/sdpd-service.c
+++ b/src/sdpd-service.c
@@ -125,6 +125,8 @@ static void update_svclass_list(void)
case INTERCOM_SVCLASS_ID:
case FAX_SVCLASS_ID:
case SAP_SVCLASS_ID:
+ case HEADSET_AGW_SVCLASS_ID:
+ case HANDSFREE_AGW_SVCLASS_ID:
val |= 0x40; /* Telephony */
break;
case AUDIO_SOURCE_SVCLASS_ID:
--
1.5.5
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Nick,
> >> So I looked at the headset and handsfree spec, they do not require
> >> that AG's set the telephony bit. sigh.
> >>
> >> But I can tell you for a fact that the Nokia 616 carkit will not pair
> >> unless you set the telephony bit. That is what triggered this patch.
> >
> > that looks like a really broken device to me. How can it pass the
> > qualification if it mandates that bit. Is PTS setting it by accident.
> >
> >> We have yet to find a device (and we have tested hundreds now) that is
> >> not compatible because of the telephony bit. It is a safe change to
> >> make.
> >
> > Check your patch with PTS headset/handsfree and the IOP part.
>
> Yeah thats worth checking. I can't check until Wednesday when I am
> back in the office with the PTS tester. I'll post back results.
you can also file an errata to have the headset and handsfree
specification fixed. If they agree that the telephony bit should been
set.
> > I am not
> > sure if we can just enable service bits as we like.
> >
> > So in case I can be convinced to take this patch, it has to be in a
> > separate case statement and with a comment that the Nokia 616 is just a
> > plain stupid broken device and that is why we did it. The spec. doesn't
> > mandate this.
> >
> > I also realized that the Nokia 616 might just is lucky in the interop
> > department since most phones also implement DUN, FAX or SAP and thus the
> > telephony bit is set.
> >
> > This brings me to another question, why don't you just use the serial
> > proxy support we have and point it to one of the multiplexed TTYs of
> > your GSM unit. Then you get DUN support and that broken Nokia device
> > would also work :)
>
> I wish, but this is not an option for us.
That might be actually the reason why the Nokia 616 is so stupid. They
only tested it with phones that also implement DUN or SAP. And you can
still contact Nokia and point them to the headset/handsfree specs. for
this issue.
> > So what about the desktop case that enables HS-AG and HF-AG? Are these
> > phones? Does headset profile really mean that you have to be phone. Not
> > likely. With the GSM requirements of handsfree, maybe.
>
> Both HSP and HFP are intended for telephony. I can't see any harm in
> the desktop case in setting the telephony bit, after all it will let
> them work with the Nokia 616.
It is really not about harm or not. We have to make sure to be compliant
here. The service class bits are not the brightest that the SIG ever
produced, but at least the specs. are pretty clear when to set them and
when not.
If other companies would finally implement Simple Pairing and thus be
allowed to enable Extended Inquiry Response, then this problem would
finally go away. With EIR you get the UUID and can easily identify which
service is available. Did I mention that BlueZ does already support
Simple Pairing and Extended Inquiry Response :)
And don't try to convince me for the headset case. I am not fixing that
one. The spec. says here what it says. For the handsfree we can debate
this, but currently I am in a more restrictive mode and push back on
what the spec. says. It is up to you to proof that this will not break
other application or profile qualification.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sat, Aug 30, 2008 at 3:04 AM, Marcel Holtmann <[email protected]> wrote:
> Hi Nick,
>
>> So I looked at the headset and handsfree spec, they do not require
>> that AG's set the telephony bit. sigh.
>>
>> But I can tell you for a fact that the Nokia 616 carkit will not pair
>> unless you set the telephony bit. That is what triggered this patch.
>
> that looks like a really broken device to me. How can it pass the
> qualification if it mandates that bit. Is PTS setting it by accident.
>
>> We have yet to find a device (and we have tested hundreds now) that is
>> not compatible because of the telephony bit. It is a safe change to
>> make.
>
> Check your patch with PTS headset/handsfree and the IOP part.
Yeah thats worth checking. I can't check until Wednesday when I am
back in the office with the PTS tester. I'll post back results.
> I am not
> sure if we can just enable service bits as we like.
>
> So in case I can be convinced to take this patch, it has to be in a
> separate case statement and with a comment that the Nokia 616 is just a
> plain stupid broken device and that is why we did it. The spec. doesn't
> mandate this.
>
> I also realized that the Nokia 616 might just is lucky in the interop
> department since most phones also implement DUN, FAX or SAP and thus the
> telephony bit is set.
>
> This brings me to another question, why don't you just use the serial
> proxy support we have and point it to one of the multiplexed TTYs of
> your GSM unit. Then you get DUN support and that broken Nokia device
> would also work :)
I wish, but this is not an option for us.
>
> So what about the desktop case that enables HS-AG and HF-AG? Are these
> phones? Does headset profile really mean that you have to be phone. Not
> likely. With the GSM requirements of handsfree, maybe.
Both HSP and HFP are intended for telephony. I can't see any harm in
the desktop case in setting the telephony bit, after all it will let
them work with the Nokia 616.
>
>> So sure, you can reject the patch on the basis that it is not mandated
>> by the specification. But if you care about compatibility then it
>> seems like a good change to make. Especially since you now ignore the
>> service class in hcid.conf so there is no easy way to override.
>
> Even before you had no way to set. The automatic service bit
> manipulation would have overwritten it. You can actually just call out
> to hciconfig if you really wanna overwrite it, but that is a pretty bad
> idea. It gives you more pain than anything else.
>
> Regards
>
> Marcel
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Nick,
> So I looked at the headset and handsfree spec, they do not require
> that AG's set the telephony bit. sigh.
>
> But I can tell you for a fact that the Nokia 616 carkit will not pair
> unless you set the telephony bit. That is what triggered this patch.
that looks like a really broken device to me. How can it pass the
qualification if it mandates that bit. Is PTS setting it by accident.
> We have yet to find a device (and we have tested hundreds now) that is
> not compatible because of the telephony bit. It is a safe change to
> make.
Check your patch with PTS headset/handsfree and the IOP part. I am not
sure if we can just enable service bits as we like.
So in case I can be convinced to take this patch, it has to be in a
separate case statement and with a comment that the Nokia 616 is just a
plain stupid broken device and that is why we did it. The spec. doesn't
mandate this.
I also realized that the Nokia 616 might just is lucky in the interop
department since most phones also implement DUN, FAX or SAP and thus the
telephony bit is set.
This brings me to another question, why don't you just use the serial
proxy support we have and point it to one of the multiplexed TTYs of
your GSM unit. Then you get DUN support and that broken Nokia device
would also work :)
So what about the desktop case that enables HS-AG and HF-AG? Are these
phones? Does headset profile really mean that you have to be phone. Not
likely. With the GSM requirements of handsfree, maybe.
> So sure, you can reject the patch on the basis that it is not mandated
> by the specification. But if you care about compatibility then it
> seems like a good change to make. Especially since you now ignore the
> service class in hcid.conf so there is no easy way to override.
Even before you had no way to set. The automatic service bit
manipulation would have overwritten it. You can actually just call out
to hciconfig if you really wanna overwrite it, but that is a pretty bad
idea. It gives you more pain than anything else.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Nick,
> > src/sdpd-service.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/sdpd-service.c b/src/sdpd-service.c
> > index cf120b8..df9017e 100644
> > --- a/src/sdpd-service.c
> > +++ b/src/sdpd-service.c
> > @@ -125,6 +125,8 @@ static void update_svclass_list(void)
> > case INTERCOM_SVCLASS_ID:
> > case FAX_SVCLASS_ID:
> > case SAP_SVCLASS_ID:
> > + case HEADSET_AGW_SVCLASS_ID:
> > + case HANDSFREE_AGW_SVCLASS_ID:
> > val |= 0x40; /* Telephony */
> > break;
> > case AUDIO_SOURCE_SVCLASS_ID:
>
>
> do you have a reference to a spec. for this one. The automatic
> service
> class adjustment has been done according to the spec.
>
> I didn't even know there existed a spec for these service classes. I
> thought they were rather arbitrary. But it certainly makes sense that
> if offer headset or handsfree audio gateway you are a telephone.
you wish, but it doesn't work this way. Every profile spec. clearly
states which service classes have to enabled for every role. Like it
clearly shows how the SDP record has to look.
I spent quite some time getting this done so no developer has to worry
about service classes anymore. So I really need the reference from the
headset and hansfree specs. before I touch this.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sat, Aug 30, 2008 at 2:28 AM, Marcel Holtmann <[email protected]>wrote:
> Hi Nick,
>
> > > src/sdpd-service.c | 2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/src/sdpd-service.c b/src/sdpd-service.c
> > > index cf120b8..df9017e 100644
> > > --- a/src/sdpd-service.c
> > > +++ b/src/sdpd-service.c
> > > @@ -125,6 +125,8 @@ static void update_svclass_list(void)
> > > case INTERCOM_SVCLASS_ID:
> > > case FAX_SVCLASS_ID:
> > > case SAP_SVCLASS_ID:
> > > + case HEADSET_AGW_SVCLASS_ID:
> > > + case HANDSFREE_AGW_SVCLASS_ID:
> > > val |= 0x40; /* Telephony */
> > > break;
> > > case AUDIO_SOURCE_SVCLASS_ID:
> >
> >
> > do you have a reference to a spec. for this one. The automatic
> > service
> > class adjustment has been done according to the spec.
> >
> > I didn't even know there existed a spec for these service classes. I
> > thought they were rather arbitrary. But it certainly makes sense that
> > if offer headset or handsfree audio gateway you are a telephone.
>
> you wish, but it doesn't work this way. Every profile spec. clearly
> states which service classes have to enabled for every role. Like it
> clearly shows how the SDP record has to look.
>
> I spent quite some time getting this done so no developer has to worry
> about service classes anymore. So I really need the reference from the
> headset and hansfree specs. before I touch this.
>
>
So I looked at the headset and handsfree spec, they do not require that AG's
set the telephony bit. sigh.
But I can tell you for a fact that the Nokia 616 carkit will not pair unless
you set the telephony bit. That is what triggered this patch.
We have yet to find a device (and we have tested hundreds now) that is not
compatible because of the telephony bit. It is a safe change to make.
So sure, you can reject the patch on the basis that it is not mandated by
the specification. But if you care about compatibility then it seems like a
good change to make. Especially since you now ignore the service class in
hcid.conf so there is no easy way to override.
Nick
On Sat, Aug 30, 2008 at 1:58 AM, Marcel Holtmann <[email protected]>wrote:
> Hi Nick,
>
> > src/sdpd-service.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/sdpd-service.c b/src/sdpd-service.c
> > index cf120b8..df9017e 100644
> > --- a/src/sdpd-service.c
> > +++ b/src/sdpd-service.c
> > @@ -125,6 +125,8 @@ static void update_svclass_list(void)
> > case INTERCOM_SVCLASS_ID:
> > case FAX_SVCLASS_ID:
> > case SAP_SVCLASS_ID:
> > + case HEADSET_AGW_SVCLASS_ID:
> > + case HANDSFREE_AGW_SVCLASS_ID:
> > val |= 0x40; /* Telephony */
> > break;
> > case AUDIO_SOURCE_SVCLASS_ID:
>
> do you have a reference to a spec. for this one. The automatic service
> class adjustment has been done according to the spec.
I didn't even know there existed a spec for these service classes. I thought
they were rather arbitrary. But it certainly makes sense that if offer
headset or handsfree audio gateway you are a telephone.
I could have
> missed one or two, but I am quite sure I didn't. So while it looks okay,
> we have to make sure that we didn't violate the specs.
>
> Regards
>
> Marcel
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
Hi Nick,
> src/sdpd-service.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/sdpd-service.c b/src/sdpd-service.c
> index cf120b8..df9017e 100644
> --- a/src/sdpd-service.c
> +++ b/src/sdpd-service.c
> @@ -125,6 +125,8 @@ static void update_svclass_list(void)
> case INTERCOM_SVCLASS_ID:
> case FAX_SVCLASS_ID:
> case SAP_SVCLASS_ID:
> + case HEADSET_AGW_SVCLASS_ID:
> + case HANDSFREE_AGW_SVCLASS_ID:
> val |= 0x40; /* Telephony */
> break;
> case AUDIO_SOURCE_SVCLASS_ID:
do you have a reference to a spec. for this one. The automatic service
class adjustment has been done according to the spec. I could have
missed one or two, but I am quite sure I didn't. So while it looks okay,
we have to make sure that we didn't violate the specs.
Regards
Marcel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sat, Aug 30, 2008 at 1:32 AM, Nick Pelly <[email protected]> wrote:
> On Sat, Aug 30, 2008 at 3:04 AM, Marcel Holtmann <[email protected]> wrote:
>> Hi Nick,
>>
>>> So I looked at the headset and handsfree spec, they do not require
>>> that AG's set the telephony bit. sigh.
>>>
>>> But I can tell you for a fact that the Nokia 616 carkit will not pair
>>> unless you set the telephony bit. That is what triggered this patch.
>>
>> that looks like a really broken device to me. How can it pass the
>> qualification if it mandates that bit. Is PTS setting it by accident.
>>
>>> We have yet to find a device (and we have tested hundreds now) that is
>>> not compatible because of the telephony bit. It is a safe change to
>>> make.
>>
>> Check your patch with PTS headset/handsfree and the IOP part.
>
> Yeah thats worth checking. I can't check until Wednesday when I am
> back in the office with the PTS tester. I'll post back results.
Colin retested IOPT and some HFP with the telephony bit set. Pass.
>> I am not
>> sure if we can just enable service bits as we like.
>>
>> So in case I can be convinced to take this patch, it has to be in a
>> separate case statement and with a comment that the Nokia 616 is just a
>> plain stupid broken device and that is why we did it. The spec. doesn't
>> mandate this.
>>
>> I also realized that the Nokia 616 might just is lucky in the interop
>> department since most phones also implement DUN, FAX or SAP and thus the
>> telephony bit is set.
>>
>> This brings me to another question, why don't you just use the serial
>> proxy support we have and point it to one of the multiplexed TTYs of
>> your GSM unit. Then you get DUN support and that broken Nokia device
>> would also work :)
>
> I wish, but this is not an option for us.
>
>>
>> So what about the desktop case that enables HS-AG and HF-AG? Are these
>> phones? Does headset profile really mean that you have to be phone. Not
>> likely. With the GSM requirements of handsfree, maybe.
>
> Both HSP and HFP are intended for telephony. I can't see any harm in
> the desktop case in setting the telephony bit, after all it will let
> them work with the Nokia 616.
>
>>
>>> So sure, you can reject the patch on the basis that it is not mandated
>>> by the specification. But if you care about compatibility then it
>>> seems like a good change to make. Especially since you now ignore the
>>> service class in hcid.conf so there is no easy way to override.
>>
>> Even before you had no way to set. The automatic service bit
>> manipulation would have overwritten it. You can actually just call out
>> to hciconfig if you really wanna overwrite it, but that is a pretty bad
>> idea. It gives you more pain than anything else.
>>
>> Regards
>>
>> Marcel
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Bluez-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel